On 11 June 2013 20:23, Kinkie <gkin...@gmail.com> wrote: > On Mon, Jun 10, 2013 at 7:22 PM, Alex Rousskov > <rouss...@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 <rbtcoll...@hp.com> Distinguished Technologist HP Cloud Services