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 17:08:08 -0800 (PST)

    > From: Colin Walters <address@hidden>

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

    > So what happens if the continuation points to an archive not managed by
    > archd?  I think in this case we'll just have to return an error.

Nope. 

        DELTA $archive * $revision

invariably returns the changeset that is stored for $revision.  It
should only ever fail if $revision is an import revision.  You should
never need access to the tagged revision to compute

        DELTA $archive * $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.

    > Ah, I see you're addressing that here.  

Not the (non-)problem you described but (true) problem you were
thinking of.

    > So from the client perspective, they will try to get the delta
    > they're interested directly from the server.  If that returns an
    > error, then they could fall back to retrieving the individual
    > deltas and following continuations on their own?

Right.


    >>     The Parts header returned by the server MUST contain a list
    >>     of positive integers, separated by commas. =20

    > The rest of the protocol separates things by spaces, BTW.

"whateva" :-)


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

    >>  arch_compose_changesets

    > This would be useful actually even outside of this context, as part of a
    > "changeset-utils" package.

You bet!

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

    > It's called archive-archd.c BTW :)

Sorry.

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

    > Yeah.  But for replay, the client actually *wants* separated
    > changesets; perhaps we also need a header where the client asks
    > for the changesets to be broken up individually?

The archive.h vtable can still keep "get_revision" and client code can
use that to get individual changesets.

get_revision can, indeed, be implemented by 

        DELTA $archive * $revision

in the wire protocol.



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

    > Yeah, I like that flexibility.  If you have a beefy enough server,
    > computing and caching deltas server-side could be a win.

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

For that matter, (later, of course) we could extend the protocol to
permit:

        DELTA $archive1/$revision1 $archive2/$revision2

and think about cases where a single server or local fs is hosting
multiple archives.   We want to avoid _too_ much non-determinism that
would have arch commands searching all over the world for a server
that can optimize some case but I'll bet we can do something nifty
along these lines.


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

    > Well, log searching is a much less well-defined thing than computing a
    > delta.  There's many different headers, and different ways you might
    > want to search them; i.e. give me all revision numbers where the author
    > is "Tom Lord" and the Standard-date is between two days ago and 7 days
    > ago.

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)

-t





reply via email to

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