Re: Should we remove ESI?

On 11 June 2013 20:23, Kinkie <gkinkie_at_gmail.com> wrote:
> On Mon, Jun 10, 2013 at 7:22 PM, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:

> 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.

It is a generic trie implementation, it is very good at some forms of
lookup, and it's used in ESI yes; I had planned to try it in the HTTP
parser, but ETIME.

>> 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).

We get occasional queries about it on IRC and the lists; I don't know
if it's in use in production or not. I think it would be sad to remove
working code, but if noone is using it, noone is using it.

I think refactoring it to use eCap rather than clientStreams would be
fine, but I can't volunteer to do that myself.

-Rob

-- 
Robert Collins <rbtcollins_at_hp.com>
Distinguished Technologist
HP Cloud Services