Re: [xsl] Client-side compiled XSLT/DOM Persistence (was Re: [xsl] [XSL] XSL Browser Integration)

[Robert Koberg <rob@xxxxxxxxxx>]

On Sun, 2007-09-16 at 14:41 -0600, M. David Peterson wrote:
> On Sun, 16 Sep 2007 14:31:15 -0600, Robert Koberg <rob@xxxxxxxxxx> wrote:
> 
> > I don't know how to make
> > it persistent.
> 
> Have you compared the Silveright isolated storage[1] with the Flash-based  
> persistence?  In particular does the Flash-based storage allow persistence  
> in any capacity once the browser has been closed and/or the primary domain  
> has been left?  For that matter can you access the storage if the primary  
> domain is the same but the URI's path segment has changed, or is this a  
> "stays alive only for the life of the page"-type solution.

My best guess is that it can only stay alive for the life of the page,
but I have seen some pretty amazing stuff with JS in the past year or
so.

I assume you need some way to serialize the processor object and I don't
see any way to do that other than the XSL's XML representation upon
which it was created. 

I also wonder how much would be gained by reading back in a serialized
processor object (if it were possible) versus just rebuilding a DOM
(free threaded in MS's case) and creating the object. Probably
something, but maybe in the 100s of ms range???


> 
> Adding to this, has anyone played with GoogleGears[2] and successfuly  
> persisted DOM objects of any type?
> 
> [1] http://silverlight.net/QuickStarts/IsoStore/default.aspx

After a /quick/ look at Silverlight, it looks like it does not create a
DOM, rather it reads the XML file stream. It looks like java's SAX.

best,
-Rob

> [2] http://gears.google.com/