Re: DOM based API

On Jun 6, 2008, at 11:58 AM, Mark Baker wrote:

> On Fri, Jun 6, 2008 at 12:58 PM, Maciej Stachowiak <mjs@apple.com>  
> wrote:
>> What are the advantages?
>
> I hope my response to Anne demonstrated some of them.

Your response (which I didn't see at first because part of the thread  
was cross-posted and part wasn't) said:

> There might be value in making it a Node in another document (or a  
> DocumentFragment), sure. But if you mean why reuse the DOM at all,  
> I've actually got a blog post waiting in the wings on that subject,  
> but the gist of the value is that rather than requiring developers  
> learn new interfaces specific to some task, to reuse a generic  
> interface like the DOM where possible, reducing the learning curve  
> and enabling the serendipitous reuse of on-device data (more on that  
> at a later time).
> Consider the example of a script wanting to register for an event  
> when the device leaves a predefined location. One can obviously  
> write a custom access (e.g. the current Gears proposal) & eventing  
> API for that, or one can just make all that information available as  
> a Document and then register for a mutation event when the value of  
> the "currentLocation" element of that document changes.


I disagree that this reduces the learning curve or makes things easier  
for developers. First, accessing parts of a generic DOM document with  
known names and attributes doesn't really mean "no new API", it just  
replaces a real API with a string-based pseudo-API.  
geo.getElementsByTagName("currentLocation") 
[0].getAttribute("lattitude") is not any easier to learn than  
geo.currentLocation.lattitude, but it it more verbose and more error- 
prone.

I particularly disagree as to DOM mutation events as a change  
notification mechanism. DOM mutation events are confusing and not  
widely used by authors, and they have terrible semantics both for  
correct implementation and for ease of authoring. For example, many  
seemingly primitive DOM operations have to dispatch mutation events  
partway through and so may only partially succeed!

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.



>
>
> BTW, I'd also add that I liken this approach to that of procfs[1], aka
> "/proc" on Linux.  As Linux/Unix is very much file based, it seemed a
> natural choice to expose OS and hardware information via files.  To
> me, it seems just as natural a choice to expose Web-client-side
> information via documents.
>
> [1] http://en.wikipedia.org/wiki/Procfs
>
> Mark.