On 6/11/2013 11:23 AM, Kinkie wrote:
On Mon, Jun 10, 2013 at 7:22 PM, Alex Rousskov
<[email protected]> 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
+1 from me to that.
Eliezer
