gnu-arch-users
[Top][All Lists]
Advanced

[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: Fri, 30 Jan 2004 12:46:09 -0800 (PST)



    > From: Colin Walters <address@hidden>

    >>  (2) design your protocols so they can be streamed
    >> (instead of a series of short operation-replies, allow a bunch of 
operations
    >> to be sent as a batch, with well-defined behavior in the case of 
mid-batch
    >> failure).

    > What commands specifically do you see being used in this
    > context?  The only one that comes to mind at the moment is
    > making 'abrowse' more efficient.  Maybe more will arise though
    > when I get to comitting and such.


I'm no so sure that general purpose streaming is a particularly useful
strategy for most arch operations.

In general, streaming is going to require the client-side application
logic to generate lots of requests before consuming the data they
return.  That's awkward, client-side, and there's only a few special
cases where it would be worthwhile.  More importantly: I think that
those special cases will most often have better solutions than
(literal) streaming.

An example is `update'.   Sometimes `update' will read a long list of
changesets one after the other.   So you'll get something like:


        client                     server

        getrev $A patch-N  ------>

        [apply      <------------- reply with changeset
        changeset]

        getrev $A patch-N+1------>

        [apply      <------------- reply with changeset
        changeset]

        [repeat at length]


One _could_ do this instead as:

        getrev $A patch-N  ------>
        getrev $A patch-N+1------>
        getrev $A patch-N+2------>
        [...]

        [apply      <------------- reply with changeset
        changeset]

        [apply      <------------- reply with changeset
        changeset]

        [...]

but why bother with that?   I think the better thing to
do is to raise the level of the protocol a bit by adding:

5.X DELTA Command

    Arguments: archive, from-revision, to-revision
    Specific Headers: Parts-limit, Parts
    Payload: yes

    This command returns a changeset or changesets describing the
    differences between from-revision and to-revision.

    From-revision may be * indicating "the immediate ancestor of
    to-revision".  If to-revision is a continuation revision, the
    immediate ancestor is the tagged revision.

    If from-revision is *, then to-revision must not be an
    import revision.

    Server implementations are not required return a changeset
    for all valid arguments.  If from-revision is not * or
    is not the immediate ancestor of to-revision, then implementations
    MAY instead return an error.  Otherwise, the correct changeset
    MUST be returned.

    Under some circumstances, the server may return more than 
    one changeset.   The composition of the changesets returned
    describes the differences between the two revisions.

    The Parts header returned by the server MUST contain a list
    of positive integers, separated by commas.  The sum of these
    must be equal to the Content-length.   The payload is a
    concatenation of changesets, the lengths of which are specified
    by the Parts header.

    The client MAY include a Parts-limit header containing a single,
    postivie integer.   The server MUST NOT reply with a greater
    number of changesets than that.


Client-side, this can be provided by new function added to the
archive.h vtable.

        arch_archive_delta ([...])

Unlike the wire protocol, arch_archive_delta will always return a
_single_ changeset.

We'll need a (client-side) function:

        arch_compose_changesets

which can compose two changesets if they have the property that after
the successful application of the first to any tree, the second will
cleanly apply as well.

archive-walter.c can use arch_compose_changesets to assemble the
"parts" that it gets from the server.

Minimally, archive-pfs.c can always return 0 (no changeset) for
arch_archive_delta.

It would probably be a simple performance win if archive-pfs.c
actually _did_ use arch_compose_changesets to produce a changeset in
the case where from-revision is an ancestor of to-revision.

The strategy used by `update' can be modified to attempt to use
arch_archive_delta in preference to a `replay'-like strategy of 
reading several changesets separately.

Other merge commands can take good advantage of
arch_compose_changesets as well.

The advantage of this approach over streaming is that it can be
implemented in two ways (or a mix of two ways): Changeset composition
can take place either client-side or server-side.

I think there are other cases where we'll want streaming-like behavior
but not literally streaming.   Making `archive-mirror' go faster comes
to mind.   Commands that search a large number of archive logs in
order to compute some result based on their headers come to mind.  In
both cases, it seems useful to me to make ambiguous whether certain
computations take place server-side or client-side and so (literal)
streaming is not the right answer.

-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]