[webkit-dev] AppCache class naming (WAS Re: SharedWorkers alternate design)

[Michael Nordman]

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<jorlow at chromium.org> wrote:
> On Thu, May 28, 2009 at 4:32 PM, Michael Nordman <michaeln at google.com>
> 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.
>