[whatwg] Proposed changes to the History API

[Jeremy Orlow]

I see.  It makes more sense why you mentioned the session storage element
then.  Note that there has been some discussion about whether session
storage should survive crashes, but I know Safari and Chrome are currently
planning to _not_ serialize it to disk.
I don't have any good use cases for allowing DOM objects.  And, if history
is going to be recoverable, I completely agree that we shouldn't allow that.
 I still think we shouldn't force app developers to serialize everything to
strings.  Maybe we can just raise an exception if they try to set the
history state to something unserializable?  (I guess that's what you're
already doing?)

On Thu, Aug 20, 2009 at 11:05 AM, Justin Lebar <justin.lebar at gmail.com>wrote:

> On Wed, Aug 19, 2009 at 5:31 PM, Jeremy Orlow<jorlow at chromium.org> wrote:
> > but here it seems like everything can just stay in memory...right?
>
> My thought was that if you had a tab open and restarted the browser,
> that the state objects would be there after the restart, so we'd have
> to serialize to disk.  I also thought that we'd persist this state
> data even after we take a Document out of memory.
>
> It might be possible to store some subset of DOM objects while still
> meeting those requirements, but that seems like it might be a serious
> can of worms.  Do you have a use case which would be facilitated by
> being able to store some DOM objects in this way?
>
> -Justin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090820/8d69d718/attachment-0001.htm>