Re: [xslt] XSLT and Safari

On Aug 16, 2004, at 5:02 PM, Mark Vakoc wrote:

--- Dave Hyatt <hyatt apple com> wrote:

I was planning on walking the DOM myself to find out that information. Our stylesheet loading code already deals with imports and recursion defense and so on.

Seems to me you are causing yourself significant additional work with greater
risk by taking this approach.

With a sync I/O approach, you lose all ability to parallelize loads. If one sheet wants to import three other sheets (A, B, and C), then libxslt's model will force you to load A, then load B, and then load C. My model will allow me to kick off all three loads at once. This seems clearly better to me. If B loads first and wants to import two more sheets (D and E), I could get those loads kicked off even before A or C had finished, etc.

That is what I currently do and would recommend it. I have a very long running
(may be several minutes long) XSLT transformation. It is contained entirely
with it's own thread. The user interface is held within a different thread so
that menu items, toolbar buttons, etc. can be functional during the
transformation. When the long running thread is done it updates the UI and the
user experience is never interrupted.

Yeah, it might be reasonable to push the transformation itself onto a separate thread, although the problem is that other browsers have JS APIs that are synchronous, and so we'll have to have that as well. Since client JS in a Web page runs on the UI thread (this is true in both Mozilla and Safari), you'll block the UI anyway. If you don't, you end up becoming re-entrant, since you could then trigger UI events on your DOM and execute more JS.

Our loading model is asynchronous, so what I wanted to do was simply get everything loaded myself up front so that when libxslt asked for stylesheets I could synchronously hand them back without having to do I/O.

If I understand you are using existing asynchronous services to read the
resources into memory. Once the documents are all there you then want to run
the transformation, having it return as quickly as possible. You should
consider the case of a long running XSLT stylesheet. For legitimate or not so
legit reasons a stylesheet may take a very long time. If I understand your
approach correctly you will have minimized any user inconvience during parsing
time but not during the actual transofrmation.

Correct. The transformation will currently lock up the UI.

 And how can you possibly handle the document()
function that can have it's arguments dynamically built (and hence no
way to
know before transformation) the URI to parse/include?

We probably would not handle this in an initial release if the transformation expects to block while doing synchronous I/O.

Hmm.. the document() function is part of the XSLT 1.0 spec. I would state that
a non standards conformant processor is worse than none at all.

If you put the libxml2/libxslt processing into it's own thread for the duration
of it's "work unit" then you need not change as much in libxslt. Not sure if
this is possible in your situation but has worked very well for me.

Yeah, while I'd like to do parallel loading of the stylesheet resources, it definitely seems smart to do the transform on its own thread, although we'd have to invent our own DOM API for asynchronous transformations, but maybe I could get Mozilla to buy off on that idea.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]