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: Colin Walters
Subject: Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes
Date: Fri, 30 Jan 2004 16:47:18 -0500

On Fri, 2004-01-30 at 15:46, Tom Lord wrote:

> An example is `update'.   Sometimes `update' will read a long list of
> changesets one after the other. 

Right - more roundtrips.

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

I like this idea.  We can just toss GETPATCH and express it as a trivial
case of DELTA.

However, what happens if a client actually wants 

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

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

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

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

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

Makes sense.

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

> 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 :)

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

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

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

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


reply via email to

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