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

[Maciej Stachowiak]

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<jorlow at chromium.org>  
> 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 <michaeln at google.com 
>> >
>> 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<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.
>>>>
>>
>>