[Top][All Lists]
[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
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Zack Weinberg, 2009/08/24
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Markus Wanner, 2009/08/24
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Timothy Brownawell, 2009/08/24
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Timothy Brownawell, 2009/08/24
Re: [Monotone-devel] netsync flag day justifies bumping version number to 1.0, Stephen Leake, 2009/08/25