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

[Colin Walters]

On Sat, 2004-01-31 at 21:33, Walter Landry wrote:

> The current situation can be vastly improved with just a smarter
> client.  The current client is much more inefficient than it has to
> be.  It should be able to download things in parallel, instead of
> waiting for the result of one result before continuing on.  For
> example, for a simple get, you do one or two directory listings to
> find the latest revision, and then a whole lot of listing in parallel
> to find the latest cached revision and continuation revisions.

First, this depends very much on the underlying transport.  I don't
think FTP or SFTP are pipelinable.  HTTP/1.1 is, but it's read-only.
Opening multiple simultaneous connections is pretty evil (server
overhead, defeating TCP congestion control).

And moreover, note that there might be no cached revisions at all.  Some
people expect that users of their archives create a local mirror with
cacherevs themselves, or use a revlib.  It then becomes pure overhead to
search through all the revisions looking for a cacherev, even with
pipelining.  

A smart server could just say up front that there are no cacherevs, and
the client could immediately start retrieving from the last continuation
or import advertised by the server.

> > o Execute post-commit hooks on the server when a revision is committed
> > o Ability to have very flexible authentication and access control
> > o Removing the need for a shared Unix account for multiple committers
> 
> These can already be done using arch-pqm or simple extensions to it.
> You don't really have to define a wire protocol for this.

Yes, I know, having written arch-pqm ;)  But it's really a different
beast.  arch-pqm is very indirect, and for some projects where you want
to run the regression tests before *any* commit, that's an overall win.

But for a project where you just want to share an archive, it's
basically overhead.  I like the flexibility and immediacy of direct
access - for example, replaying just a few patches into the central
archive instead of star-merging.  Could we add a "replay" command to
arch-pqm?  Yes...but it's just not the same thing as doing 'tla replay
...; tla commit'.

> Couldn't you do a poor man's version of this with a cron job?  It
> would look over the logs, figure out which revisions are popular, and
> cache those.

Sure.  It would just be easier with archd.

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