On Wed, 02 May 2007, Hyrum K. Wright wrote:
> Daniel Rall wrote:
...
> > Wouldn't this would require opening multiple RA sessions to the
> > repository? (Meaning multiple TCP sockets, in the usual case.)
>
> Nope. We send multiple log messages serially down one RA session now,
> don't we?
Yes. I'd understood your description to mean that you'd be making
multiple RA 'log' calls, which looks like was not your intent.
> This scheme requires that the children be sent in-band, right after the
> parents. That wouldn't require any additional connections than the one
> that we are currently using.
>
> Maybe an example here might help:
> Assume a simplified (x, y) tuple to represent the log message for
> revision x with child_count y. Using the last example in the functional
> spec, the series of messages would be:
> (24, 2) (14, 0) (12, 2) (10, 0) (9, 0)
>
> This unambiguously defines the tree, which can be rebuilt by clients
> that need it. Our client doesn't, and can just spit the messages out in
> the order it gets them.
That example cleared things up, thanks Hyrum. It wasn't obvious to me
that you intended to send down the child log info (which was my
concern).
You're thinking that we can implement this scheme using an optional
child_count parameter, the presence of which changes the handling of
subsequent log info?
> >> If it is a case of convenience, we could provide a receiver function for
> >> clients that builds the log message tree.
*nod*
> > The command-line client will always need the data in tree form when
> > invoked with the --merge-sensitive option (which I'm assuming will be
> > a new boolean on the RA log API). In terms of network I/O, it'd be
> > less efficient to require O(N) RA calls than a single call which
> > fetches all the data. Yes, the data will come down in a potentially
> > "jerky" fashion (for deeply nested trees, which won't be the usual
> > case), but will remain streamy for log info with no nesting. I'm not
> > sure what this means in terms of CPU usage and disk I/O on the
> > repository-side; we may need to profile to determine the best
> > strategy.
>
> Why will the command line client always need the data in tree form? The
> end result is output to the terminal, which is serialized, and basically
> a preorder traversal of the message tree. If we serialize the messages
> through the ra session in the same way, why do we need to construct and
> then traverse the tree at the client? We should be able to just spit
> out the messages as they come, with appropriate merge tracking
> information pulled from the baton.
...
We are still constructing a tree representation on the repository side
-- you're suggesting a different representation (pre-order traversal)
for marshalling the data, which does sound good.
- application/pgp-signature attachment: stored
Received on Wed May 2 20:29:04 2007