[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implement
From: |
Tom Lord |
Subject: |
Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes |
Date: |
Sun, 1 Feb 2004 12:22:36 -0800 (PST) |
> From: Sylvain Defresne <address@hidden>
> On Sat, 2004-01-31 at 21:01, Tom Lord wrote:
> > 1) it calls apply_patch only once -- thus it addresses our
> > client side inefficiency
> > 2) _if_ a server can compute and return that delta directly,
> > that completely solves our network latency and bandwidth
> > issues. It's exactly one roundtrip and the changeset returned
> > is as compressed as it could possibly be.
> > The caveat is, of course server-side costs but that's a
> > worthwhile trade off in a number of circumstances.
> I'm new to tla and to this list, so I may have mis-understood
> something. But how does this server-side delta computation interact with
> signed archive ?
In general, smart-servers don't use the form of signing that dumb-fs
servers currently do. That's flexible, actually: one _can_
implement a smart server that does -- but as you note, that same smart
server couldn't do server-side delta combination in the general case.
> I was under the impression that each changeset is
> signed independently, and I don't see how the delta can be signed since
> the server. Or does this only work for non-signed archives ?
Signing as currently implemented is dumb-fs specific. It's purpose
is to allow someone to look at an fs-archive and make sure that it's
contents haven't been modified. The ".check" features of tla allow
that checking to be mixed with tla's reading from an fs-based archive.
The prototype smart-server archive storage format that Walters is
creating could easily be adapted to record signatures just like (or
just enough like) dumb-fs archives. But the larger question is:
should (and if so how should) signing be made a part of the wire
protocol he's designing? In designing the wire protocol, he has to
think not only about server implementations that just stash the
literal tar bundles a client sends -- but also about server
implementations that unpack those and use a different format
internally; and, as you note, about server implementations that are
trusted to produce results (such as composed changesets) that no
client produced.
-t