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

[Tom Lord]

    > 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