Re: Should we remove ESI?

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.

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

I am willing to assist with the eCAP APIs necessary for the conversion,
but I cannot volunteer to work on ESI removal or the ESI adapter,
unfortunately. Perhaps somebody who uses ESI can help?

$0.02,

Alex.
Received on Mon Jun 10 2013 - 17:22:21 MDT