Lists Home |
Date Index |
* 'Liam Quin' <email@example.com> [2005-08-17 14:55]:
> On Wed, Aug 17, 2005 at 06:53:41PM +0100, Michael Kay wrote:
> > Achieving (b) though is really hard, given that the URI might in the
> > worst case identify a random number generator. The only real way to do
> > it is to serialize a private copy of the document to disk.
> You could also behave differently depending on the URI scheme --
> an extension to say "trust http expiry times and that the stylesheet
> will take no more than 3 hours to run :-) and trust that input files
> won't change on disk" might be interesting.
> > The real problem though is in deciding when it's a good idea to discard the
> > document. For example, if the stylesheet is working its way through the
> > @href links from the primary source document, what's the chance that you'll
> > want to visit the same target document more than once?
> Are there some special cases that are big wins in prctice?
> E.g. consider:
> <xsl:template match="foo">
> <!--* load a 500MByte XML file: *-->
> <xsl:variable name="oed" select="doc('oed.xml')" />
> <!--* do stuff with the dcument *-->
> <xsl:element name="word-of-the-day">
> <xsl:copy-of select="/dictionary/a/entry[@id = 'ascii'] />
> if you don't know how often the template matches I can see that you
> might want to cache the whole document in memory, but you have a
> couple of other choices --
> (1) save the result of the template -- in this case it doesn't depend on
> anything other than the input document, and I've seen this usage
> often, e.g. to get a document title
> (2) drop the document if you get low on memory
> This case is very clear, but I don't know at what point it stops
> being optimiseable, and I'm sure you've thought about it a lot more
> than I have! :-)
> > That's why I decided that in this case having a user function to
> > tell me when the document is no longer needed is rather more
> > useful.
> I think it's a good compromise, but I agree with you it'd be hard
> to get consensus to add that to XPath F&O.
I want to note that Momento is designed to accomodate this
requirement of XSLT.
When a Momento document is referenced in a concurrent
application, a thread that references the document observes a
snapshot of the document.
Other threads can modify the document, but those changes will
remain invisible to the snapshot. The version of the document
observed by the snapshot remains in memory and backed on disk
until the last snapshot referencing it terminates.
It doesn't work across processes, yet. Momento is designed for
multi-threaded applications, and it's simple to fashion a
Momento server, or to embed it in a Servlet.
The Momento document is a thread safe implementation with
interfaces for concurrent operation.
Alan Gutierrez - firstname.lastname@example.org