Re: [xslt] XSLT and Safari

[Dave Hyatt <hyatt apple com>]

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.

dave