On Wed, May 27, 2009 at 12:13 AM, Maciej Stachowiak <[email protected]> wrote:
> > On May 27, 2009, at 12:00 AM, Jeremy Orlow wrote: > > On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak <[email protected]> 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. > :-) Point taken. > 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. > I'll try to come up with something better, but one of these should work if nothing else. > > 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. > Don't worry. I actually think naming is a pretty big deal since it makes a big difference in the readability of code and it's really hard to change a name in the future. J
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
