Re: Should we remove ESI?

On 12/06/2013 8:52 a.m., Kinkie wrote:
> On Tue, Jun 11, 2013 at 5:00 PM, Alex Rousskov
> <rousskov_at_measurement-factory.com> wrote:
>> On 06/11/2013 02:23 AM, Kinkie wrote:
>>> On Mon, Jun 10, 2013 at 7:22 PM, Alex Rousskov
>>> <rousskov_at_measurement-factory.com> 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.
>> And there are other similar tools around -- we use one in Web Polygraph
>> IIRC. It would be a good project to compare them and use the best for
>> HTTP header lookup if (and only if) they show noticeable improvement.
>> Then, depending on the winning tool, the best integration option can be
>> found.
>>
>>
>>> 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).
>> Yes, but even bigger ESI-associated problems are, IMO:
>>
>> * ESI adaptations are not appropriate for a built-in Squid component.
>> The content adaptation that ESI performs should be done using an
>> optional module or service. If eCAP has (or can be enhanced to have)
>> enough hooks, eCAP should be used for that. Otherwise, another API can
>> be provided for all similar adaptations.
>> * ESI may be the only big user of Client Streams, an unfinished API that
>> is responsible for many client side problems. If there is no ESI, it
>> would be much easier to restore client side code sanity.
>>
>> I agree that an inquiry on squid-users and a separate email to ESI
>> sponsors is a good step forward _if_ there is no squid-dev consensus
>> that ESI must stay as an integrated component.
> The consensus that ESI should ideally be turned into an eCAP module is
> overwhelming.
> As is the consensus that so far noone has the time to do it :(
> What is the second-best option?

Second best option is to leave it alone for a while longer. It is
currently in a mostly-working state with nobody either complaining or
requesting new feature changes to it.
I am getting along with re-architecting the client-side okay for now
despite its existence. If it ever gets in the way too much it will get
my attention at that time.

The bigger problems for the re-arch effort right now are parser,
SSL-bump, and tunnel.cc all playing with the client socket in special ways.

NP: Alex and Kinkie if you two are able to focus any more effort on the
StringNG project it would be great. I am nearly ready to start proposing
parser design patches and I would much rather do that with SBuf
capabilities.

Amos
Received on Thu Jun 20 2013 - 15:35:51 MDT