Subject: Re: Client-side compiled XSLT/DOM Persistence (was Re: [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
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/
|