Re: Memoization

On Thu, Aug 22, 2002 at 02:49:28PM +0200, [email protected] wrote:
> On Thu, Aug 22, 2002 at 08:13:21AM -0400, Daniel Veillard wrote:
> >   Hum, there is no such mechanism, the only way would be to add an
> > interface to libxslt to plug-in a document cache. Note that for a single
> > transformation all the document() result are cached (this is actually
> > required by the XSLT spec), but there is no mechanism for a more global
> > cache. Could make sense, could be very small change if one doesn't
> > try to implement a default cache in libxslt itself.
> 
> Ah, this is an interesting topic. What could actually be cached?
> Won't an xml document like the following:
> 
> <doc>
>   <a>&blub;</a>
> </doc>

  document() will parse *complete* documents so there is no risk.

> resolve to a different result depending on the entity declaration
> in the importing document?

  it's not an import mechanism, and even though import at the XSLT level
does import complete document too.

> The really imteresting point (IMHO) would be: is it posible to
> "compact" a parsed XML document (read: xmlDoc) to a memory area
> of known size so it can be shared be means of shared memory?

  You're mixing issues it seems. 1/ compacting in memory representation
and 2/ sharing parsed trees. 1/ sounds impossible and precompiled XML
makes IMHO very little sense unless your parser is dead slow (think Java).
2/ is already possible as long as you either don't modify the xmlDocPtr
or make sure the reader/writer scheme allows only one write or
only reads at any time.

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
[email protected]  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/