3 ms·
I think that the mechanism I suggested elsewhere would handle this best: each tab's complete state (DOM, JavaScript &c.) should be marshalled to disk at quit (a
by zeveb 10y ago
I think that the mechanism I suggested elsewhere would handle this best: each tab's complete state (DOM, JavaScript &c.) should be marshalled to disk at quit (and checkpointed periodically, in case of crashes); on startup, all tabs are loaded and their DOM & JavaScript contexts restored. If a tab's context had it set to update periodically, then that periodic-update context would be restored; if not, then the remote server would never be contacted until and unless the user hits reload.
This seems so obviously correct to me that I wonder what I'm missing.
- kuschku 10y ago> This seems so obviously correct to me that I wonder what I'm missing. You are missing that > should be marshalled to disk at quit is not easily doable.
- zeveb 10y agoWhy not? The DOM is, ultimately, just HTML. The VM state is just data in RAM, which should be eminently serialisable. I'd think it's the sort of thing which ought to be child's play.
- kuschku 10y agoThe VM state isn't that easy when you remember that JS can keep open sockets to other things, can launch processes, etc. Sure, you could find a way to serialize it, but that'd be a lot harder — you can't hust go back to halfway the middle of receiving something through a socket.
- zeveb 10y agoOne could just close open connexions — after all, a network connexion can always die anyway. I really hope that JavaScript in a browser can't launch processes!