[webkit-dev] SharedWorkers alternate design
jam at google.com
Wed May 27 15:37:04 PDT 2009
On Wed, May 27, 2009 at 12:00 AM, Jeremy Orlow <jorlow at chromium.org> wrote:
> On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>> On May 26, 2009, at 6:11 PM, Jeremy Orlow wrote:
>>> Did you say partly because it's more complicated than just splitting one
>>> class (and only having 1-way sync communication)? If so, then we're still
>>> on the same page, because that's what I'll be doing as well. I was just
>>> using the StorageBackend as an example, but events will require signals from
>>> the backend to the frontend, and some abstractions (like StorageArea) make a
>>> lot of sense whether or not things are split into two pieces, which sounds a
>>> lot like what you described with ResourceHandle.
>> As a side note - I think it would be cool if we used more specific names
>> than "Backend" and "Frontened" in the actual code, since which end is front
>> and back is not always obvious nor always agreed upon by all observers. I
>> like Proxy and Impl ok as name pairs, not sure if that's the same
>> relationship you have in mind.
> I somewhat disagree regarding the terms frontend and backend being
> confusing. It seems to me that the backend is always further away from the
> user than the frontend. Same thing with client and server. That said, I've
> definitely heard complaints about terms like this before (on other
> projects), so I'm not married to the terms.
> The names I was planning to use were outlined in a design doc I sent to
> this list (http://docs.google.com/View?id=dhs4g97m_8cwths74m). Basically,
> I was planning to the term Backend, but the rest of the names are more
> descriptive. If you have another suggestion for Backend, I'd be happy to
> change it. I would have already, but the only other idea I had was server,
> and I think people find that term even more confusing. StorageRepository
> might be an ok name.
> As for Impl and Proxy, they are actually somewhat orthogonal to the
> frontend and backend. For example, if a script calls
> window.localStorage.setItem(foo, bar), the frontend in the render process
> will access the backend proxy which will send the message to the browser
> process where the backend implementation lives. The backend implementation
> will then access the EventManagerProxy which will distribute the events to
> the EventManagerImpl in all the render processes. In other words, Proxies
> are necessary anywhere messages originate.
Just as a data point: Chrome uses Proxy/Impl naming for a variety of classes
WebPluginDelegateProxy/WebPluginDelegateImpl). The code is also moving to X
and XClient for the two-way API for feature X. If possible, it would be
good to match these names for the sake of consistency.
StorageImpl (lives in the process that opens the database)
StorageProxy (in multi-process browser, lives in the renderer process and
StorageClientImpl (receives event that value changed)
StorageClientProxy (in multi-process browser, lives in the browser process
and notifies above)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev