Chris Leishman wrote:
Really? I didn't notice that... AFAIK a Content-Length header is only actually returned when delivering from a cache file (apache calculates the content-length, etc, after the $r->filename is set and the handler declines). When delivering normally I noticed that there is no Content-Length header (although HTTP/1.1 connections used chunked encoding which is preferable to content length anyway).
The content-length was different because the content returned was different. See below.
hence, if only the DOM is returned, there may be unexpected results.
AFAIK my patches should change this situation at all. At the moment a language module can return a dom (via pnotes), or just a string. And the next module has the opportunity to look for the dom or the string in pnotes. So are you saying that there are actually differences in the output under the new patches, because that seems strange...
It does change it, though. Your patched version always returns a DOM instance, the current version serializes the result to a string using the XSLT processor's output_string( $result ) if the current process is $last_in_chain. The difference is that the latter *alters* the output based on options that may be set in an <xsl:output/> element in the stylesheet itself. The last stylesheet in my test suite had
<xsl:output mode="html"/>
(which is fairly common) so, when your patched version just returned the DOM result, the XSLT processor didn't get a chance to do its HTML mode serialization tricks (stripping of the XML declaration, adding meta headers for encoding, etc.) like it does in the current Language::LibXSLT-- hence the results are different,
Its not a big deal, all it takes is checking $last_in_chain and returning the result of output_string( $result ) if its defined instead of always returning the DOM.
I don't see any reason why AxKit should serialise and re-parse at each stage. If a language processor is known to be broken wrt using a prebuilt DOM, it can query the provider for get_strref and then parse it's own DOM internally. It would be silly to impose that overhead if the modules being used don't need it. It would also encourage people to fix bugs that stop it working properly.
Agreed. I didn't want it to go away either. The combination of the above XSLT output annoyance and Simon Woodside's recent "bug" w.r.t. serializing default namespaces made me a little touchy. What can I say, I'll try the decaf...
* It wasn't clear to me whether or not the new Language module design allows direct output to the client if the current processor is the last in the chain. If not, this presumption puts limits on what can be integrated as last-in-chain Language modules that may need access to the Apache object to return content appropriately.
The last-in-chain module can't output directly to the client, since the response should be returned to AxKit for it to deliver. But I don't think the previous code did either. I noticed some modules (eg. LibXSLT) took the effort of serialising the DOM and printing it if last-in-chain was in effect, but the AxKit::Apache module simply redirects the print and puts the data in pnotes('xml_string') anyway - so it's still not dynamic (and is thus kind of pointless....maybe this is historic?).
Er, that is pretty silly, actually...
* Bolting on the result of the transformation to the return code in the new Language modules (e.g. return (Apache::Constants::OK, \%results); ) seems a smidge hacky to me. They should return one or the other, both is an ugly mix of coding strategies.
It is a smidge hacky I agree. I did it to be backwards compatible. I guess the same could be achieved by returning a hashref with a 'status' member, and then detecting whether a scalar or a hash ref was returned by the processor back in AxKit.
+1
So, I guess the sum of my evaluation is "I'm not sure". There are definitely some good things in the proposed patches, but I think they go too far in some places.
I'm not sure you've really said where in particular they 'go to far'...
Well, really the only part I was worried about was shutting down direct access to sending data to the client from the Language modules, but, given that its only there in an illusory way now anyway, it really doesn't matter.
.
The questions that need to be answered are:
In general, does switching to incremental caching give us something that we don't already have, or is it arguably a better generic solution than the current all-or-nothing implementation (especially in light of the fact that the typical use-case seems to put the dynamic parts at the front of the processing chain)?
Well, it buys you advantages in the cases where dynamic parts are later in the chain. And I still haven't heard an overly convincing argument for why that shouldn't be a far more appropriate thing in many cases. My view is that XSP by nature is a form of 'styling', and should be added in rather than being in the original XML document.
XSP (eXtensible Server Pages) is all about *generating* content. It is not a transformative processor in the way that XSLT and XPathScript are. There is no XSP stylesheet that gets applied to a source document and there's nothing in the language itself that presumes an input document.. Markup, inlined code, and taglibs (markup that maps to code) are combined in one document and the only "transformation" happens when the XSP processor executes the inlined or taglib-added code.
So, unless you mean "a pipeline of styles that generates an XSP page that gets executed at the end to generate further content" I'm not sure what you mean by using XSP as "form of styling". Its not that you *couldn't* do things that way, but its hardly the common case. The XSP(to generate content)->XSLT(to style it for the given client) pattern is far more common.
Here's what I suggest:
1) Accept the patches.
2) Re-implement the current all-or-nothing" caching behavior of the current Cache.pm using the new interfaces and keep this behavior as the default.
3) Ship Cache::Incremental (or whatever) as a standard alternative.
Reasonable? Doable? Anyone have thoughts?
[ all: please change the subject to create a new thread if you want to discuss this point with me further. The initial discussion on this was on -users with the topic 'Adding XSP to an XSLT pipeline'. ]
This discussion is not appropriate for the user's list; that's why I brought it here. If you want to continue in the conversation you are certainly most welcome and what you do with the subject line in your replies is your business. :-)
-kip
