Re: Should we remove ESI?

On 11/06/2013 8:54 p.m., Robert Collins wrote:
> On 11 June 2013 20:23, Kinkie wrote:
>> On Mon, Jun 10, 2013 at 7:22 PM, Alex Rousskov 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.

Yes. I know of a few installations actively using it as of about a year
ago. One newspaper in .il, a blog installation, and some form of
mapping/game system.
I have tried experimenting with it a little myself, but run into
problems with Apache and the surrogate pieces.

The big lack of take-up has been that in the past it required a
specialty build of Squid and we have not exactly promoted it much since
it was polished up for default-enable in 3.1. The alternative XHR /
jQuery / node.js mechanisms are quite well known, slightly more flexible
and work without a proxy.

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

Ditto.

Amos
Received on Tue Jun 11 2013 - 10:24:36 MDT