Re: Should we remove ESI?

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.

> I do not know much about ESI, but IMHO, if somebody has cycles to work
> on this, it would be best to spend them removing ESI (together with
> libtTrie) from Squid sources while converting ESI into an eCAP adapter.
> This will be a big step forward towards making client side code sane
> (but removing ESI itself does not require making complex changes to the
> client side code itself).

Robert is the expert on this. My question right now is, is anyone
using ESI? ESI requires a specifically-crafted mix of infrastructure
and application; there are nowadays simpler ways to obtain similar
results.
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).

--
    /kinkie