ESI Support for <esi:vars>

[Poul-Henning Kamp]

In message <CAOCFVZjft8NXFv9D5P_dLjXgzWo_gxPyYPS6-B12c-Woe6HfNQ at mail.gmail.com>
, Stefan Mai writes:

>Is there any work being done on adding support for additional ESI
>constructs (such as esi:vars)? If not, would the core devs be willing to
>consider a possible patch (from me) adding support for a few additional
>constructs (as well as updated documentation)? I'd like to add this
>functionality but I want to also make sure it has the possibility of making
>it into upstream if the quality is up to snuff.

Good patches are always welcome :-)

I have no objections to esi:vars on any grounds of principle, but
last I looked, which was basically when we added ESI in the first
place, I saw a number of implementation details which caused be to
put it outside the boundary of our ESI implementation.

Since then the ESI parser was rewritten with extension of the ESI
feature-set in mind, but I didn't revisit esi:vars specifically.

It's probably a good idea, if you try to write an outline of how
you want to tackle the implementation and pass it by -dev first,
so that you don't spend a lot of time on stuff we can answer or
head down a wrong turn without us knowing.

Other than that:  Go for it.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.