Re: pseudo-specs for a String class

>> Basic design goals: refcounted, cheap copying, string parsing and
>> slicing; reasonably-cheap appending (due to strings being
>> almost-immutable).
>>
>> I'll put the incomplete code somewhere (Launchpad, probably) for
>> everyone to review in a few days at most. So far it seems promising,
>> in about 100 lines of code I have implemented memory management,
>> instantiation, assignment, appending and some debugging (and certainly
>> quite a few bugs).
>
> Well the implementation itself is going to be relatively simple. The
> problem isn't the implementation - the problem, as I've said before,
> is fixing all the existing Squid String users.

Yup. You might notice that working on the callers (aka users) has been
a constant pattern in anything I've coded in the past 60 days.
This is the reason why I'm doing this in a quite naive manner... to
have a sane interface to get callers to use.

> Doing scatter/gather type IO tricks on refcounted buffer regions isn't
> all that difficult. Squid's IO patterns make a naive-ish
> implementation fine - since the majority of "large" buffers will have
> to hang around until the end of the request (to keep the request/reply
> headers intact) you're not going to waste any RAM by just keeping the
> one large buffer in memory versus trying to break it up and only keep
> what is being referenced in memory.

Agreed. Let's also keep in mind that having a few tens of kb's around
for the lifetime of a request is not where the real waste is.. if we
wish squid to start using less memory we need to attack the cache
index issue.

> I think I mentioned this on IRC earlier - the design which worked for
> Squid-2 is a reference counted buffer and then a string layer on top
> mapping in the {offset, length} into the backend buffer. I also
> thought about a buffer "reference" which included the {offset, length}
> so you can use it in places like stmem without having to use Strings.
> I tended to want to use "strings" where string-like semantics existed
> (ie, all the data manipulation methods that help define a "string"
> behaviour) and buffers for socket data.

In fact I'm not claiming I invented anything new.. my only claim is
that I "just started doing it". Not sure even where this will go - if
it'll go anywhere.
In my opinion there is not that much of a difference between Strings
and Buffers, and the latter could use the services of the former to
delegate the issues of memory management, while concentrating on
different aspects - joining, chaining, vector I/O come to mind.

> I suggest you check out the changes I made in s27_adri to achieve all
> of this in a sensible fashion. The bulk of the String related usage is
> the same between Squid-2 and Squid-3. You may also have C++ compiler /
> language related stuff to "get right" which I didn't have to deal with
> in C (copy constructors, type conversion, etc) but I'm sure it won't
> be difficult to do if done piecemeal.

Will do. If I won't port over, I'll still borrow what I can :)

-- 
 /kinkie