Re: pseudo-specs for a String class

Adrian Chadd wrote:
> 2008/8/27 Amos Jeffries <squid3_at_treenet.co.nz>:
>
>> memory region doesn't. A string is generally a representation of
>> printable data; a memory region isn't."
>>
>> .. particularly that last sub-sentence.
>
>> Um, and per your:
>> " Would you use a "String" as the reference counted type for say, the
>> memory store? "
>>
>> Yes. I would. I really don't like Java, but their object serialization
>> concept can be made very efficient for specific cases like HTTP Header
>> storage. Completely removing any duplicate parsing (speed!) on load of
>> object bytes from disk etc.
>
> Well sure, and we need to do something long-term about the header vs
> reply body storage in store objects, but thats a later problem.
>
> Parsing the HTTP headers should be a bloody quick process.
>
>> Minimal size cost is disk space of ((2xINT + PTR)*N + INT) though, where N
>> is the number of tokens in the array of Strings. +(PTR * H + INT) if its
>> done as a full tree (where H == header count).
>
> But you miss my earlier point - would you use _string_ for storing the
> _reply_ information in the memory store? The reply headers? sure. The
> reply body chunks? :)
>

I see no reason why not. Beyond the size argument. Which is a
red-herring anyway. It's only the classical std:string functions which
won't work on binary.

And whose to say we won't one day want to do object byte-wise body chunk
comparisons with something exactly equivalent to String::strcmp()?
(ie storeurl_rewrite object equivalence validation)

Or supply range requests using likewise, something exactly equivalent to
String::substr(A,B) and String::strlen()?

Amos

-- 
Please use Squid 2.7.STABLE4 or 3.0.STABLE8