Re: Calendar API: navigator ?

On Wed, Apr 20, 2011 at 4:13 PM, Robin Berjon <robin@berjon.com> wrote:
> Hi João,
>
> thanks a lot for your feedback.
>

Hi again !

> We've had that discussion quite a few times. Essentially it boils down to this: we like to avoid polluting the global namespace, so we tend to avoid putting things on window unless it is absolutely necessary;

Global namespace pollution is a valid argument, but this is not
variable leaking or a poorly designed legacy API. It would be a single
clean entry point, with a properly structured and organized API, so
the pollution argument is not fair.
Necessity should also dictate that APIs should not be polluted with
unrelated features.

> and more importantly, the geolocation API, which is already widely deployed, has its entry point on navigator.

I know about geolocation and also think it was a poor choice. But
that's done and deployed. This isn't.

> It makes sense to follow in their path since a lot of developers are already familiar with that. Putting those APIs on the same access point makes them clearer. It is not rare that in specifying something we have to forget about the semantics of a name and go with common practice.

I don't find it clearer, I find it more convoluted. I don't understand
why it would be less "clear" to developers not having navigator
before. Are developers that naive ? I don't think so.

> In general, if you think about it, all of these APIs (geolocation, calendar, contacts, etc.) are extra services that the user agent (i.e. the navigator) makes available to the page. So maybe it even sort of makes sense semantically :)
>

The same could be said for practically anything: local storage,
indexed db, networking and so on. All extra "services" from the user
agent. :)

My reasoning boils down to this:
 - it's against the semantics of the navigator object
 - one more unneeded indirection, more typing
 - clean APIs are not global namespace pollution

Thank you.

Received on Wednesday, 20 April 2011 15:53:38 UTC