W3C home > Mailing lists > Public > public-geolocation@w3.org > June 2008

Re: DOM based API

From: Maciej Stachowiak <mjs@apple.com>
Date: Sun, 8 Jun 2008 19:38:18 -0700
Cc: public-geolocation@w3.org
Message-Id: <0474F871-CD33-4CA9-A6D8-0723E45AAF1A@apple.com>
To: Mark Baker <distobj@acm.org>


On Jun 8, 2008, at 7:22 PM, Mark Baker wrote:

> Yes, I'm aware of that.  I think the modified-cdata event was wrong
> bundled up as a mutation event, and should have been separate.
> Perhaps we can create a new event that doesn't come with the mutation
> baggage.
>
> But these kind of issues are inevitable any time reuse is considered.
> It's nice to be able to start with a clean state (a custom API), but
> as we all know as Web developers, there's considerable value in
> reusing already deployed technologies, warts and all.

I've not seen Web developers having a problem with the fact that many  
APIs in the browser are not DOM trees. The main conceptual reuse I see  
as valuable is the concept of DOM events, whether tied to DOM nodes or  
not. The fact that occurrences related to non-Document-tree objects  
such as Window and XMLHttpRequest are represented as Events on an  
EventTarget allows for useful code reuse, since there are many  
libraries building on top of DOM-style event handling.

So I see promise in using DOM Events for change notification (such as  
ongoing location monitoring) but not in representing location data as  
a DOM tree.

>
>> For specific kinds of data supported natively by the UA, we should  
>> use
>> native APIs, not generic APIs with a document structure convention  
>> layered
>> on top.
>
> What do you mean by "native"?

I mean, design APIs that is specific to the problem domain, rather  
than representing the data as a DOM tree and then access it with  
generic APIs. In my experience with API design this has proven to be  
the best approach.

Regards,
Maciej
Received on Monday, 9 June 2008 02:38:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:39 GMT