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