On Mon, 15 May 2000, Honza Jirousek wrote:
> Alternatively some sophisticated signaling mechanism controlling caching
> from caller to sablotron could be developed, but that would be almost equal
> to full cache management by caller.
Almost equal, but I get uncomfortable when the scope of mechanisms
increases before it's even been implemented. Why not start with an
internal cache and an ability to arbitrarily invalidate stuff, and take it
from there if/when it proves necessary?
> 2) The caller will possibly cache more types of information than Sablotron,
> and incorporating parsed XSL and XML cache into caller's cache would save on
> both code size (single caching module) and the cache size (coordinated space
> management).
I don't see this. It gets particularly sticky when you cross language
boundaries: Publishing Perl and Python interfaces for the tree
system...ack.
> object. All you need is to design a way to return parsed tres from Sablotron
> and supply them as Sablotron call parameters. The latter could be done
> similarly to named XML trees in parameters, say with names starting with
> "parsed:". The caller should be responsible for allocating and deallocating
> these. Returning the parsed trees from Sablotron is a bit harder, as it's
> unclear who will allocate the memory for them and how - it should be the
> caller, but he can't know how much is needed.
Yep.
> I haven't followed the discussion on caching efficiency in detail, but I
> assume we have already proven that caching the parsed trees have an
> "economic" sense.
Inside the existing code, Sablotron already parses an XML and XSL files
into trees and traverses the tree structure. "Caching" XML trees in this
case just means refraining from "forgetting" the tree structure, so it's
really for "free".
Assuming there's a nontrivial amount of value in a single XSL application,
it gets more important when you have a chain of 5 or so transformations.
Being able to keep the result tree for each step and applying it to the
next as an XML document would eliminate the output-to-XML as well as
input-from-XML. If you have 5 transformations for a page, and maybe 50 XSL
files for the site, it can all add up fast.
> Note that the option of the caller understanding the full structure of
> sablotron-parsed XML would make sense as well, particularly in a case where
> caller's own representation of parsed XML would be identical. Often the
> caller will construct the XML document for Sablotron on the fly, and
> handling it over to Sablotron directly would allow to eliminate the
> conversion to string and parsing by Sablotron. This is much harder, and
> should be considered independently from the discussion above.
Yes. One step at a time.
