On May 29, 2009, at 12:10 PM, Michael Nordman wrote:
Frontend/Backend was my first choice too... based on how we ended up
discussing the split of things, seemed natural... maciej wasn't too
keen on that thou...
@Maciej, any strong objections or opinions?
I still think we should avoid using such ambiguous terms such as
Frontend/Backend. (Also, if we did, they should be spelled as
FrontEnd / BackEnd since in English they are two words.) Just to
demonstrate one way this might be confusing: one might reasonably
assume that in Chrome, the renderer process is the back end, and the
browser process is the front end. But it sounds like the use of your
proposed classes would be opposite of that - the "back end" class
would be used by the "front end" process. I continue to think that
FrontEnd and BackEnd as name distinguishers are about as helpful as
"A" and "B" or "1" and "2". Yes, they do mark the difference, but they
don't really explain what it is.
I can make suggestions in the context of reviewing a patch if you guys
don't want to discuss it any more. I'm not clear enough on how exactly
you split the classes to make a good suggestion.
Regards,
Maciej
On Fri, May 29, 2009 at 12:04 PM, Jeremy Orlow<[email protected]>
wrote:
Ha....Kitchen/Counter were an attempt to push thinking in the right
direction, not a real suggestion.
Agree that this is a rat hole and it we need to move on.
Still think Frontend/Backend is the clearest thing despite being
used in a
different manner in some other places and despite Client/Server(/
Service)
being used elsewhere. But Client/Service is my second choice.
J
On Fri, May 29, 2009 at 11:57 AM, Michael Nordman <[email protected]
>
wrote:
I really have no strong opinions one way or the other (or the
other),
so long as its somewhat intelligible I'm good.
Having said that....
Kitchen and Counter don't pass muster for me :)
Bindings mean script bindings... not gonna overload that for this
Intelligible options any of which work for me so far
* FooFacade FooSystem
* FooFrontend FooBackend
* FooClient FooService
We should wrap this rat hole up.
On Fri, May 29, 2009 at 11:16 AM, Jeremy
Orlow<[email protected]> wrote:
On Thu, May 28, 2009 at 4:32 PM, Michael Nordman <[email protected]
>
wrote:
Can you think of a more specific way to describe the
reationship than
"front" and "back" or "client" and "service"? Does one of the
Gang of
Four
Design Patterns apply? That can be a good resource for clear
ways to
describe class relationships, even fairly abstract ones.
Nice suggestion...
In my case Facade may be the most appropriate name for what i've
been
referring to as the 'frontend' interface. I'm endeavoring to
provide a
simplified interface (a facade) to a more complex system, the
moving
parts of which are not important to clients of the facade.
Inside that Facade, Proxy may be the most appropriate for the
messaging abstraction parts.
ApplicationCacheFacade
* uses ApplicationCacheSystemProxy
ApplicationCacheSystem
* uses ApplicationCacheFacadeProxy
WDYT?
I'm not really sure this is a Facade pattern. I think a good
example of
the
facade pattern is the WebKit to WebCore relationship: a complex
inner
system
that's made to be easy to use via the facade.
Personally, I find the names less clear than Client/Server (or
Backend/Frontend).
What if we could come up with some more clear synonyms for
Backend/Frontend? Another way to think about it is that the
frontend is
the
seating area (or counter) of a resteraunt and the backend is the
kitchen.
What other metaphores along these lines would be similar? Maybe
something
about Storage vs Bindings (since the one half is about storing
everything
and the other is about hooking it into the resource loading)? I
don't
know....just trying to brainstorm here.
_______________________________________________
webkit-dev mailing list
[email protected]
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
