Daniel Rall wrote:
> 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.
Yeah, sorry if I was unclear about that before. It is still logically a
tree, but the transmission format uses the above representation. I'll
clarify the spec.
-Hyrum
Received on Wed May 2 20:38:52 2007