[Top][All Lists]
[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
- [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Colin Walters, 2004/01/29
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Miles Bader, 2004/01/29
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Andrew Suffield, 2004/01/29
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Robert Collins, 2004/01/30
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Andrew Suffield, 2004/01/30
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Robert Collins, 2004/01/31
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Colin Walters, 2004/01/29
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Tom Lord, 2004/01/30
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Colin Walters, 2004/01/30
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes,
Tom Lord <=
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Colin Walters, 2004/01/30
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Tom Lord, 2004/01/30
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Aaron Bentley, 2004/01/30
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Colin Walters, 2004/01/30
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Aaron Bentley, 2004/01/31
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Tom Lord, 2004/01/30
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Aaron Bentley, 2004/01/31
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Tom Lord, 2004/01/31
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Andrew Suffield, 2004/01/31
- Re: [Gnu-arch-users] RFC: arch protocol, smart server, and tla implementation prototypes, Aaron Bentley, 2004/01/31