xsl-list
[Top] [All Lists]

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

2007-09-17 04:02:46
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(_at_)koberg(_dot_)com> 
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/



--~------------------------------------------------------------------
XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--