On May 27, 2009, at 12:00 AM, Jeremy Orlow 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.
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.
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
