[webkit-dev] Local Storage naming (WAS Re: SharedWorkers alternate design)

[Jeremy Orlow]

On Wed, May 27, 2009 at 12:13 AM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On May 27, 2009, at 12:00 AM, Jeremy Orlow wrote:
>
> On Tue, May 26, 2009 at 9:40 PM, Maciej Stachowiak <mjs at 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.
>

:-)  Point taken.

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

I'll try to come up with something better, but one of these should work if
nothing else.


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

Don't worry.  I actually think naming is a pretty big deal since it makes a
big difference in the readability of code and it's really hard to change a
name in the future.

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20090527/ceb82d3c/attachment.html>