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

[Tom Lord]

    > From: Colin Walters <address@hidden>

    >> Music to my ears.   Stick an optional server-side revlib in there,
    >> too.

    > How would a server-side revlib work?  I thought most of the
    > efficiency of a revlib came from the hard-linking.  There isn't
    > a way to send those over the wire :)

Well, consider the proposed DELTA protocol.  (Instead of "server-side
composition" you can just compute the requested delta directly.)

Also consider that you can (though this may hair-up build_revision
heursitics) pretend that every revision is cacherev'ed.   Fork tar to
spew the payload....  (For one thing, that would perfectly optimize a
cold `get'.)

There's other reasons outside the current protocol, too.   Rapid
history of a single file?   Rapid file contents for a given revision?
Server-side browser?


    > > rel_table arch_archive_patch_log_listing (arch, revision)

    > > is the big one, I think.

    > > Could maybe be generalized to:

    > > rel_table arch_archive_headers (arch, ancestor_revision, revision)

    > But there, you have to know the revisions in advance.  What if I wanted
    > to specify things by date, as in my above example?


Well, nothing currently needs that (as contrasted with
patch_log_listing).   But, yeah, big open space here for useful things
to think about.

-t