Re: seen_offset vs copy_offset

On Wed, Dec 27, 2000, Henrik Nordstrom wrote:
> Adrian Chadd wrote:
>
> > 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.
>
> If you don't kill the header parsing you most likely cannot kill
> seen_offset. It will still be needed one way or another to defer
> processing until the required data is available.

Why?

the buffers that are being copied into are fixed size. As long
as a track the returned size from each clientcopy and only
register new copies to fill the rest of the buffer, what
could break?

I've looked through the client_side.c code. seen_offset != copy_offset
is used in:

* clientHandleIMSReply
* clientCacheHit

pump.c doesn't abuse it. urnHandleReply() in urn.c uses it but not
very intelligently.

It seems that wherever it is used, the reply types (the urn reply
and what I can only see as the status line) can't exceed the copy
buffer size.

In fact, the code in clientCacheHit() just confuses me to no end.
It keeps moving seen_offset forward if sline.status == 0 and
the object isn't completely in memory/being written out ..
Why is it doing this? I really haven't read this code through
completely ..

In any case, I can optimise out the seen_offset with a little number
juggling.

Adrian

Adrian

-- 
Adrian Chadd			"Here's five for the cake, and
<adrian@creative.net.au>	  five to buy a clue."
				    - Ryan, Whatever it Takes