Lists Home |
Date Index |
- From: Didier PH Martin <email@example.com>
- To: firstname.lastname@example.org
- Date: Wed, 13 Dec 2000 12:10:48 -0500
Ah. But I didn't say it was impossible, just impractical. I wonder about
the XSLT code and processor you're using. Suppose your super incremental
parallel includer/transformer (SIPIT) has received half of the included
fragment, and meanwhile your XSLT processor is positioned at this template:
How does it deal with the fact that it cannot complete the node-set
that matches the pattern?
Does your processor use something like DOM's live node lists, where it can
begin instantiating the template for the first few nodes in the set,
and hopefully the other nodes are dynamically added as the inclusion half
of SIPIT proceeds? I'm guessing processing would block until the end of
the node-set is inicated, in which case you face _very_ poor parallel
processing performance. Even if your processor can do this much, you have
a _very_ nifty processor, and I'd like to know where you cache the source
code so I can steal it.
If we say that the inclusion/transformation is limited to the included
fragment, then, a possible contention may happen if several times we include
fragments from the same document. In that case, we will have several cases
where we have to deal with critical sections because the other inclusion
wait for the same document. But when the document is obtained, then the
transformation may happen in parallel. Notice that I said that the
inclusions are to be limited to the included fragment. It may happen that
parallel processing may not be efficient on some cases (because of the
critical sections) but in most cases it is.
Interesting though. My turn to go impractical, but it would be
interesting if there were a Linda-like model where depending on load and
capability, the transforms could be scheduled on whatever resource was
best. Perhaps the server, perhaps the requestor. Perhaps even some
"Hey, quit transforming your XML doc with _my_ CPU cycles"
As Paul Prescod might note, I'd better patent the idea before Ray Ozzie
gets hold of it.
In fact, if the XSLT engine is already present on the user agent (or the
gateway), then the server may decide to partition the process and have the
transformation to occur on the client side. Idem for the inclusion except if
the publisher needs more capabilities than the one provided by xinclude.
However, I didn't thought about the fact that we may have to deal with a
user agent revolt :-) in that case, the only thing the server may do is...
Didier PH Martin
Conferences: xml devcon 2000 (http://www.xmldevcon2000.com)
Wireless Summit NY (http:www.pulver.com)
xml devcon 2001 London (http://www.xmldevcon2000.com)
Book: XML Professional (http://www.wrox.com)
column: xml.com (http://www.xml.com)