Re: Should we remove ESI?

On 06/11/2013 02:23 AM, Kinkie wrote:
> On Mon, Jun 10, 2013 at 7:22 PM, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 06/09/2013 02:40 PM, Kinkie wrote:
>>
>>> while attempting to increase portability to recent clang releases, I
>>> noticed that libTrie hasn't benefited from the portability work that
>>> was done in the past few years.
>>>
>>> I can see three ways to move forward:
>>> 1- replicate these changes into libTrie
>>> 2- change libTrie to piggyback squid's configuration variables
>>> 3- fully integrate libTrie into squid's build system. Unless Robert
>>> knows otherwise, squid is the only user of this library..
>>
>>
>> I cannot tell what libTrie does: The README file is empty and the commit
>> message only implies that it is an ESI component. AFAICT, only ESI uses
>> it today.
>
> From what I understand (Robert, can you come to the rescue?) libTrie
> is a very optimized key- and prefix- lookup engine, trading memory
> useage for speed. It would be great to use in the Http parser to look
> up header keys, for instance.

And there are other similar tools around -- we use one in Web Polygraph
IIRC. It would be a good project to compare them and use the best for
HTTP header lookup if (and only if) they show noticeable improvement.
Then, depending on the winning tool, the best integration option can be
found.

> For this reason I would launch an inquiry to our users and to the
> original ESI sponsors to understand whether to simply stop supporting
> ESI. It is ~10kLOC that noone really looks after, and they imply
> dependencies (e.g. on the xml libraries).

Yes, but even bigger ESI-associated problems are, IMO:

* ESI adaptations are not appropriate for a built-in Squid component.
The content adaptation that ESI performs should be done using an
optional module or service. If eCAP has (or can be enhanced to have)
enough hooks, eCAP should be used for that. Otherwise, another API can
be provided for all similar adaptations.

* ESI may be the only big user of Client Streams, an unfinished API that
is responsible for many client side problems. If there is no ESI, it
would be much easier to restore client side code sanity.

I agree that an inquiry on squid-users and a separate email to ESI
sponsors is a good step forward _if_ there is no squid-dev consensus
that ESI must stay as an integrated component.

Alex.
Received on Tue Jun 11 2013 - 15:01:01 MDT