[webkit-dev] SharedWorkers alternate design

[Jeremy Orlow]

On Wed, May 27, 2009 at 3:37 PM, John Abd-El-Malek <jam at google.com> wrote:

>
>
> 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 (i.e. WebWorkerProxy/WebWorkerImpl,
> WebWorkerClientProxy/WebWorkerClientImpl, WebPluginProxy/WebPluginImpl,
> 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.
>
> How about:
>
> StorageImpl (lives in the process that opens the database)
> StorageProxy (in multi-process browser, lives in the renderer process and
> notifies above)
>
> StorageClientImpl (receives event that value changed)
> StorageClientProxy (in multi-process browser, lives in the browser process
> and notifies above)
>

Thanks for the pointers and suggestions.  Unfortunately, in my experience,
the distinction between client/server is even more confusing to developers
than frontend/backend.  In addition, the XClient naming scheme doesn't
really fit into the design I've currently got in mind (which was documented
in the design doc I've sent out a couple times) since there are a couple
different classes that compose the frontend.  So I'm not sure it'll really
fit into my design here.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090527/2366388b/attachment.html>