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

[Walter Landry]

Colin Walters <address@hidden> wrote:
> Hi,
> 
> I've been working on a "smart server" over the past few days.  There's a
> lot to talk about, so I'll try to break it up into cleanly separated
> parts.
> 
> First, "why a smart server?".  This has been discussed on the mailing
> list in the past, but here's a far-from-exhaustive list of reasons:

I don't mean to rain on your parade, but it is not clear to me that
you really need to define a wire protocol to achieve these things.

> o Ability to have a much more efficient protocol, avoiding server 
>   roundtrips

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.
Finally, in most cases, you download all of the relevant patches and
cached revision.  A total of three or four round trips.  The current
implementation uses something like O(number of patches).  A smart
server would presumably be one round trip.  It is not clear to me that
there is enough of a difference between one and three or four round
trips.

> 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.

> o Ability to record which revisions are accessed frequently, and
>   dynamically adjusting cached revisions to match

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.

However, this does touch on another desire, which is to be able to
configure the archiving strategy [1].  That is, to be able to store
the last revision, rather than the first one.  It still sounds like
you could do something with a cron job, though.

There is also the feature that, with just a protocol, you can replace
the backend with a database.  In that case, it would probably be
better to actually create the backend database and methods to access
it locally before creating a remote protocol.

Cheers,
Walter

[1] http://savannah.nongnu.org/bugs/?func=detailitem&item_id=4787