[RFC] Pushkey Concept

[Dirkjan Ochtman]

On Sun, Sep 20, 2009 at 23:37, David Soria Parra <sn_ at gmx.net> wrote:
> A 'pushkey' capable remote repository implements a pushkey()
> call and a listkey() call. A call to listkey() returns a dictionary of
> key-value-pairs matching a given namespace. A pushkey() call pushes a
> given key-value-pair to the remote.
>
>  - puskey(string namespace, string key, string value, boolean force=False)
>  - listkeys(string namespace)

I hope you meant 'pushkey' instead of 'puskey' there? I'd prefer
pushkey to accept a dictionary like {'bookmarks': {'mybookmark':
'34abc3254'}}, so we can reduce the number of roundtrips if we want to
push many keys in one go.

> The logic to handle a pushed or pulled key is done by the code that uses
> the key. In other words, bookmarks handle bookmark keys. This is needed
> as for example bookmark might react in other ways to a --force than
> ohter uses of pushkey. To keep the protocol strict it is not planned to
> let extensions hook into the handling, meaning that all code dealing with
> pushkey and listkey remain in mercurials core.

This seems at odds: logic for transferring keys is done by the code
that uses the key, but it is not planned to let extensions hook into
the handling? Can you explain how you see that working out?

> Storage:
> Unlike earlier suggestions, I think that storing key and values should
> be done by the code that uses them. This means that bookmarks will still store
> the bookmarks in .hg/bookmarks, ensuring backward compatibiltiy and
> efficient storage. This is particularly useful if we want to use the
> pushkey concept for example with localtags.

Sounds good.

> Other open questions:
> I'm not sure how to handle large dictionaries returned by listkeys().
> Should they be pickled() or split into chunks?

How large do you think they will be? I don't think we're going into
problems very soon here. Maybe we can support HTTP zlib compression in
the protocol.

Cheers,

Dirkjan