[RFC] Pushkey Concept

[Matt Mackall]

On Tue, 2009-09-22 at 23:09 +0000, David Soria Parra wrote:
> On 2009-09-22, Matt Mackall <mpm at selenic.com> wrote:
> > Further, the whole point of bookmarks is to not have history. So
> > inventing history-based methods to transmit them is silly.
> >
> > I'm in favor of a simple key/value extension like what's being proposed.
> >
> I'm not yet sure about what to allow to be transferred. It seems that
> there is a need for extensions to hook the pushkey call, while I'm
> persoanlly favor the concept that just code in core can should use
> pushkey and we do not allow external code to hook it (well other than
> monkey patching which is always possible).

I don't see what the debate is. Push: client pushes a dict or a dict of
dicts and the server hands that dict off to every registered callback.
List: server calls every registered callback to build a dict and sends
it to client.

It seems obvious to me that an extension shouldn't be able to change the
protocol. You're either allowed to push, or you aren't (tied to normal
push permissions). The keys you push either take effect or they don't.

> 
> I think the later approach will cause less problems with extensions
> that change the way they push and pull keys.
> 
> It was also suggested to use json as a serialization mechanism.

I don't see much reason for that. It should probably more or less
emulate the modes used by the existing wire protocol commands. 

Also, don't bother with extra complexity for large key sets. If someone
ends up sending 1MB of key data, they are doing something wrong. They
almost certainly want some form of revision control for that much data.

-- 
http://selenic.com : development and support for Mercurial and Linux