[Webkit-unassigned] [Bug 25376] Refactor localStorage code for use in multi-process browsers

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Jun 5 16:32:11 PDT 2009


https://bugs.webkit.org/show_bug.cgi?id=25376


jorlow at chromium.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dglazkov at chromium.org




------- Comment #8 from jorlow at chromium.org  2009-06-05 16:32 PDT -------
I figured it might help reviewers if I explained what I'm doing in excruciating
detail.

High level overview of structure:

*DOMWindow code*
Calls LocalStorage/SessionStorage to get a storage area
Creates a Storage object and returns it to the javascript implementation

*LocalStorage/SessionStorage code*
Keeps track of *StorageArea objects associated with each origin
Handles part of the syncing issues

*StorageArea/LocalStorageArea/SessionStorageArea*
Uses StorageMap to keep track of the actual data
Dispatches events
Handles the rest of the syncing and concurrency issues

*StorageMap*
Keeps the string -> string map that is DOM Storage


Where I'm headed:

I want to reorganize everything by function.  I want to have the event
dispatching code in one place.  I want the syncing code in one place.  And I
want the data mapping in one place.  To do this, I intend to pull the factory
part of LocalStorage/SessionStorage into a StorageManager.  I want to pull the
syncing part of LocalStorage into a StorageSyncManager.  I want to pull
LocalStorageArea syncing code either into that manager or (more likely) a
StorageAreaSync class.  I want to move the event dispatching into a
StorageEventDispatcher class.

This is important for setting up proxies across processes.  For the
StorageArea, StorageManager, and their helpers, the "real" implementation will
live in Chromium's browser process (the main, unsandboxed one).  For
StorageEventDispatcher, the "real" implementation will live in the renderer
process and its proxy will live in the browser process.  If this doesn't make
sense, let me know and I'll try to flesh it out further (or update the design
doc :-)


As of right now, here's what I have planned in terms of patches.  This will
probably change, but hopefully it can give you a high level overview of where
I'm going with this:

1: Pull LocalStorage sync code into its own class.
2: Clean up the LocalStorageCode for handling the initial import.
3: Pull the rest of the sync code out of localStorageArea.
4: Pull the event dispatching code out of *StorageArea.
5: Combine LocalStorageArea and SessionStorageArea.  Combine LocalStorage and
SessionStorage into StorageManager.  All of the heavy lifting will have already
been done in other patches.
6: Made the actual proxy split.


Once again, if you have questions PLEASE ASK!  I really want to keep moving
forward on this, so I'll take whatever time necessary to explain what I'm
doing.  :-)


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.



More information about the webkit-unassigned mailing list