On Tuesday 18 March 2003 06:12 am, Chris Leishman wrote: > On Tuesday, March 18, 2003, at 10:59 AM, Matt Sergeant wrote: > <snip> > > > Well, XSP is dynamic. So in order to know when the output changes > > you'd have to be able to follow the path of the code before it is > > executed. Which is basically the halting problem. > > Ahh - I see our confusion. I agree that you can't cache the output of > XSP because it is dynamic, but Tod's original statement was that having > an XSP page generated later in the pipeline results in the page having > to be recompiled to a perl module every time. However, as long as the > source XSP comes from a reproducible source (eg. XSLT transform) then > it should be theoretically possible to cache the compiled module. > > Interestingly, this would suggest to me that it would be much more > inefficient to have XSP earlier in the pipeline - since nothing after > it can be cached.
Huh? I think you misapprehend the AxKit cacheing system.... AxKit providers have a function which AxKit calls to find out if the resource to be served has changed. The provider comes BEFORE the whole pipeline (normally its the 'file' provider, but we often replace that, still its the same no matter what). If that provider says "The resource has changed" then the entire pipeline is rerun from scratch, otherwise the FINAL output is returned to the client from the AxKit cache. Nothing IN-BETWEEN is ever cached (well, there are seperate caches for stylesheets so the pre-parsed DOM can be reused, but that isn't relevant here). Now, an XSP page is both DATA and CODE INEXTRICABLY MINGLED TOGETHER. The code can GENERATE dynamic content (think ESQL Taglib for example), but once the XSP page is compiled to perl thats it all you can do is use it as a content generator, if the XSP SOURCE changes, the page MUST be recompiled. Thus if your page is at the start of the pipeline, and a provider says "its unchanged" then the XSP page can be rerun as-is, but if the provider says the XSP has changed, then its got to be recompiled first. This is why I say that XSP is horribly inefficient later in a pipeline, because every time even just some of the DATA that that comes from earlier in the pipeline (say like some static XML tags that are part of your XSP) changes you have to recompile the XSP. This is what Matt and Co mean by 'solving the halting problem' which is to say they would need to prove that the XSP you have now is logically identical to the XSP you had before, so they can still use the precompiled module, and that is the halting problem, you cannot guarantee that you can prove it in finite time. Honestly, I don't think there is a really compelling reason to use XSP later in pipelines. I've built so far several web apps with AxKit and the times I was tempted to do so I quickly found that it was due to bad analysis of the problem on my part. You might also really want to look closely at SAX filters because they don't suffer some of these problems when used in later pipeline stages, yet they offer many of the same capabilities as XSP (or XSLT for that matter, they are rather in a middle ground there) and are also VERY efficient. SAX can often process a page 2 or 3 times faster than XSLT. > > <snip> > > > On your namespace thing, I suspect this can be alleviated with some > > changes to your XSLT to suppress or properly output XML namespaces, > > but I don't have my XSLT books to hand to figure this one out. Perhaps > > some XSLT gurus here on the list can help. > > Ok. I entirely agree that my XSLT page is broken and should be fixed. > I think the XSLT processor is probably doing the right thing by > resetting the xmlns (although having it reset to empty is annoying - > but I don't think there's an alternative). > > However there is definitely still a bug if the XSP processor crashes > when there is an empty xmlns element. Eg. this .xsp page dies for me: > > <xsp:page language="Perl" > xmlns:xsp="http://www.apache.org/1999/XSP/Core";> > <blah xmlns=""/> > </xsp:page> > > Thanks for your efforts! > > Regards, > Chris > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] -- Tod Harter Giant Electronic Brain --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
