I think it's much better idea than having Sablotron itself cache parsed XSL
and (particularly) XML trees. Caching by caller will likely be much smarter
and effective, for the following reasons:
1) Sablotron's caching may be only "blind" (that is everything is equal for
caching purposes), while caller's caching can follow custom rules, such as
"cache everything in /xxx/yyy directory indefinitely and never cache stuff
from /yyy/cgi-bin". The caller also has a better chance to notice the XSL
template of the same URI has changed and needs to be recompiled.
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.
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).
Note that both arguments are valid for Ginger Alliance's Karlik (Charlie)
platform.
As for "publishing tree interfaces", it's not so bad as it sounds - the
caller and his caching code has no need to understand the structure of the
parsed tree and can handle it as an in-memory (or even on-disk) binary
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.
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.
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.
As for those who do not wish to implement their own caching mechanism, a
wrapper library Sablocachetron could be developed, which implements the
"blind caching" for those who wish that, and could be ignored by others.
Honza
Steve Willer wrote:
>
> On Mon, 15 May 2000, Jamie wrote:
>
> > What if you made the caching the responsibility of the application?
> >
> > In some way shape or form, had the application hand sablotron a "ready made
> > tree" created from some place else that sablotron doesn't need to keep track
> > of. (Then the application can make decisions like "This stylesheet is used a
> > lot so lets keep it around") would that take away some of the burdons from
> > the sablotron library? I'm not a big object-fan, but it seems objects are an
> > ideal choice, either that or "file handle notion" of some sort.
>
> That's the traditional way of doing it, but it does mean that sablotron
> would have to publish the tree interface to the outside world. I don't
> know that there's a huge value in that.
