Re: Should we remove ESI?

On Tue, Jun 11, 2013 at 5:00 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> 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.

The consensus that ESI should ideally be turned into an eCAP module is
overwhelming.
As is the consensus that so far noone has the time to do it :(
What is the second-best option?

--
    /kinkie