Re: [Gnu-arch-users] Re: RFC: arch protocol, smart server, and tla implementation prototypes

[Robert Collins]

On Sat, 2004-02-07 at 06:36, Chris Gray wrote:
> On 6 Feb 2004, Robert Collins wrote:
> > On Fri, 2004-02-06 at 10:48, Chris Gray wrote:
> >
> >> My message was that skiplists are a data structure that you should
> >> consider for reasons of efficiency, simplicity, and size.  I feel
> >> they would be preferable to what we have now and easier to
> >> implement than a truly smart server.
> >
> > They're cute and all, but while talking smart client, dumb server
> > implementations, how do you propose maintaining signatures?
> 
> I hadn't thought of it at all.  However, committing a summary delta
> should not be any different than committing a patchset, so the
> signature maintenance should not be much harder.

You'r proposing we keep a single patch delta regardless, so the summary
deltas are just extra information? Or are you proposing we re-sign
chunks of the archive on a regular basis?

I.e. in a shared archive Tom commits base-0, patch-1 -> patch-9 in a
version. And I commit patch-10, causing a rebalance of the skiplist,
will those summaries be signed by me or Tom? How will someone who wants
to check my commits only be sure that whats in the summaries is the same
as whats in the single patch deltas?

In a nutshell: handwaving isn't enough. If you want to design a
constantly mutating storage format for a filesystem based archive
format, thats fine. But please detail how to address this issue, which
IMO is a critical one.

Rob
-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

signature.asc
Description: This is a digitally signed message part