Well, I don't know, I did suggest long ago, around 0.92 that caching should happen at every stage. The problem is you have to check every aspect of the Request, not just the URL. Currently providers decide if they 'feel' that a resource is up-to-date or not, and they can do so based on any arbitrary criteria, but at that point all is said and done. I think I recall proposing that when the pipeline is created that AxKit would then walk to pipeline and before invoking each step call a corresponding (and possibly user supplied) cache checking function. I guess thats what Jorge is now considering doing.
In any case, my point with XSP was just that you NEVER have to recompile your XSP normally unless its source changes, but if the SOURCE of the XSP is somehow dynamic, then obviously it will change often (and may not even be cacheable at all). In the case where its static XML and some XSLT then with proper caching it would indeed be 6 of one and half-a-dozen of the other as far as that issue goes. As for the problem of caching dynimic output, well, its always a problem. I mean even if I just write a mod_perl module by default Apache ALWAYS sets the cache control headers to indicate the content immediately expires and is non-cacheable... AxKit already goes partway to giving you control of that, and it could get better, but I guess we're just using XSP in different ways. I never considered it as a styling tool. I still don't see why you would want to use it that way. Styling should be done with a deterministic declarative system, its much more appropriate. On Tuesday 18 March 2003 10:35 am, Chris Leishman wrote: > On Tuesday, March 18, 2003, at 05:01 PM, Tod Harter wrote: > <snip> > > > Huh? I think you misapprehend the AxKit cacheing system.... > > Ok...let me explain my interpretation. Let me define an example of > XSLT->XSP: > > page.xml + page.xsl => page.xsp => page.xsp.compiled => page.html > > Ideally, the process would be: > > 1) if (page.xml newer than page.xsp || page.xml newer than page.xsp) > regenerate page.xsp > > 2) if (page.xsp newer than page.xsp.compiled) > compile page.xsp > > 3) Output from compiled xsp is never up-to-date (it's dynamic) so rerun > the xsp and generate page.html > > 4) page.html is the final result - send it to the client. > > Of course, if AxKit isn't currently caching the intermediate 'page.xsp' > then this doesn't work. But in theory I can't see any reason this > wouldn't work. > > > If XSP come first, it looks like this: > > page.xsp => page.xsp.compiled => page.xml + page.xsl => page.html > > In this situation we have: > > 1) if (page.xsp newer than page.xsp.compiled) > recompile page.xsp > > 2) Output from compiled xsp is never up-to-date (it's dynamic) so rerun > the xsp and generate page.xml > > 3) if (page.xml newer than page.html || page.xsl newer than page.html) > regenerate page.html ** NOTE: this is always true since page.xml > is always new > > 4) page.html is the final result - send it to the client. > > > So if nothing has changed, the XSLT->XSP case only needs to rerun the > XSP. In the XSP->XSLT case, we have to rerun the XSP _and_ reapply the > transform. Hence why I say it's less efficient. > > Obviously this analysis only applies if caching is fully implemented. > If only the first stage is cached, then the XSP->XSLT is more efficient > as you claim. But if it's an objective of AxKit to fully implement the > caching (and perhaps I'll help out J�rg to complete it), then it's > probably better not to bias people to the less efficient method. > > > 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. > > I can think of a good reason. If I want to make anything dynamic in > the 'style' of the final output, then it would have to be in the > original XSP document - which violates the idea of separating content > from style. > > If I wanted to add in, for example, a 'last modified' onto the bottom > of every page - I'd have to make all my source documents look like: > > <xsp:page> > <content>blah</content> > <last-modified><taglib:last-modified/></last-modified> > </xsp:page> > > instead of just: > > <source> > <content>blah</content> > <source> > > I'll have a look at the SAX stuff. > > Regards, > Chris -- Tod G. Harter Giant Electronic Brain --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
