monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Monotone-devel] netsync flag day justifies bumping version number t


From: hendrik
Subject: Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0
Date: Thu, 27 Aug 2009 07:10:20 -0400
User-agent: Mutt/1.5.13 (2006-08-11)

On Wed, Aug 26, 2009 at 09:57:07PM -0600, Derek Scherger wrote:
> On Mon, Aug 24, 2009 at 5:39 PM, Timothy Brownawell <address@hidden>wrote:
> 
> > On Mon, 2009-08-24 at 19:23 -0400, address@hidden wrote:
> > >
> > > Wasn't there a list of things that also needed a flag day -- with
> > > the intent that we do them all together and thus need only one flag day?
> >
> > All I'm aware of is the NetsyncTodo page, which isn't terribly concrete
> > or complete, and generally has things that we either don't know how to
> > do or haven't started on.
> >
> >
> >From the top of netsync.cc
> 
> // TODO: things to do that will break protocol compatibility
> //   -- need some way to upgrade anonymous to keyed pull, without user
> having
> //      to explicitly specify which they want
> //      just having a way to respond "access denied, try again" might work
> //      but perhaps better to have the anonymous command include a note "I
> //      _could_ use key <...> if you prefer", and if that would lead to more
> //      access, could reply "I do prefer".  (Does this lead to too much
> //      information exposure?  Allows anonymous people to probe what
> branches
> //      a key has access to.)

What is the point of this?  I don't understand.

> //   -- "warning" packet type?
> //   -- Richard Levitte wants, when you (e.g.) request '*' but don't have
> //      access to all of it, you just get the parts you have access to
> //      (maybe with warnings about skipped branches).  to do this right,
> //      should have a way for the server to send back to the client "right,
> //      you're not getting the following branches: ...", so the client will
> //      not include them in its merkle trie.

Perhaps by telling the client just what branches he *is* getting?  
Mentioning extra branches is already giving infirmation about what he 
has no access to.

> //   -- add some sort of vhost field to the client's first packet, saying
> who
> //      they expect to talk to
> 
> In case there's anything in there that we want to throw in "while we're at
> it" ;)
> 
> It seems like the usher packet might take care of the last one.
> 
> Cheers,
> Derek

How many of these things are data base issues; how many are just netsync 
protocol issues?  The latter can be done anytime once we have protocol 
version negotiation, without causing a flag day.

-- hendrik

> _______________________________________________
> Monotone-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/monotone-devel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]