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

Subject: Re: [xsl] Client-side compiled XSLT/DOM Persistence (was Re: [xsl] [XSL] XSL Browser Integration)
From: Robert Koberg <rob@xxxxxxxxxx>
Date: Mon, 17 Sep 2007 07:01:49 -0400
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

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]

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.


> [2]

Current Thread