Re: seen_offset vs copy_offset

From: Adrian Chadd <adrian@dont-contact.us>
Date: Wed, 27 Dec 2000 03:28:34 +0800

On Tue, Dec 26, 2000, Henrik Nordstrom wrote:
> If I understand the code correctly, seen_offset represents the high
> water mark for data notified to reader, while copy_offset represents the
> high-water-mark for where the reader has fully read the data.
>
> This to not require the reader to have a buffer to be able to wait for
> all required data to arrive in order to be able to process it, for
> example to defer reading of partial headers.
>
> However, the only place where such a construct is of any use is while
> reading headers, and headers should in my opinion be handled in a far
> more structured manner than a data stream (the current practice of
> decoding the headers only to pack them together into a data stream and
> then decode them again, only to one again pack them together seems like
> a big waste and nothing else).
>
> Which puts one additional requirement on reply/request objects: Then
> need to have a interface for accessing the headers, not only the data
> stream.

Right. Well, I'd like to totally kill seen_offset - from what I've seen,
I can simply "optimise" out seen_offset by tracking the buffer offset
and size rather than calling storeClientCopy with the same copy_offset
but increasing seen_offset.

I also agree that the header parsing is sub-optimal, but I believe that
for now we should focus on rewriting/improving the rest of the code,
and once its stable and working we change the interface there.

We can finish implementing my current ideas in modio without too many
changes in the client/server codebase. Changing the object data
access/format will require even more code rewriting, and I believe
they can be done seperately.

Comments?

Adrian

-- 
Adrian Chadd			"Here's five for the cake, and
<adrian@creative.net.au>	  five to buy a clue."
				    - Ryan, Whatever it Takes
Received on Tue Dec 26 2000 - 12:28:39 MST

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:13:06 MST