[webkit-dev] SharedWorkers alternate design

[Maciej Stachowiak]

On May 27, 2009, at 12:00 AM, Jeremy Orlow 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.

An example of why I think these terms can be confusing:

Which part of the style system would you guess is traditionally  
described as the "back end"? Hint: it's not the part further from the  
user. I'm glad we call it RenderStyle instead of StyleBackEnd in the  
code.


>   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.

Something like StorageRepository or StorageDataStore (despite the  
repetition) might be good. I haven't thought deeply about specific  
uses of "back end", but it's definitely something I am allergic to in  
general, as stated above.

> 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.

Thanks for clarifying.

Regards,
Maciej

P.S. I hope all this design input isn't being too fussy. Working on a  
big project like WebKit is a constant battle against entropy, and we  
try hard to find good patterns and spread them as a counter. But I  
don't mean to make a huge deal out of this naming detail.

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