Re: seen_offset vs copy_offset

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.

/Henrik

Adrian Chadd wrote:
>
> Hi,
>
> Can I please get someone to sanity check this?
>
> I'm looking at seen_offset vs copy_offset in the store client code.
>
> As far as I can tell, seen_offset is used to limit calling
> the store client completion callback even if some data is
> ready to be returned.
>
> client_side.c uses this in a coule of places - for example in
> clientCacheHit() - if size bytes have been read from
> http->out.offset but we're still waiting for the rest
> of the reply headers, we set seen_offset to http->out.offset + size.
> We still have the data, but it seems that this code throws
> the data away and re-reads it again ..
>
> Can someone familiar with the black magick in the storage manager
> please tell me whether (a) this is true, and (b) there is a real
> need to have this in the code, vs filling the remainder of
> the buffer (ie copy into buf + size, total byte length bufsize - size)..
>
> ?
>
> Merry Christmas!
>
> 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 - 08:50:27 MST