[webkit-dev] SharedWorkers alternate design

[Jeremy Orlow]

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.

Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090527/2d09d55b/attachment.html>