- From: Jeremy Orlow <jorlow@chromium.org>
- Date: Thu, 20 Aug 2009 11:20:29 -0700
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.htm>
Received on Thursday, 20 August 2009 11:20:29 UTC