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
