On Wed, May 27, 2009 at 3:37 PM, John Abd-El-Malek <j...@google.com> wrote:
> > > On Wed, May 27, 2009 at 12:00 AM, Jeremy Orlow <jor...@chromium.org>wrote: > >> On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak <m...@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
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev