Re: DOM based API

I'm with Maciej.  For geolocation, the arguments against using a DOM
tree seem stronger than the arguments for using one.  A DOM tree feels
like an unnatural fit.


On Sun, Jun 8, 2008 at 9:35 PM, Mark Baker <distobj@acm.org> wrote:
>
> On Sun, Jun 8, 2008 at 10:38 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>> I've not seen Web developers having a problem with the fact that many APIs
>> in the browser are not DOM trees
>
> That's completely beside the point.  If you invented a new Javascript
> interface for HTML5 documents, different than the HTML DOM, there
> would of course be a learning curve?  So why invent a new DOM for
> GeoLocationML documents?  At least that's how I look at this problem,
> and I don't think that perspective is any less valid than yours.
>
> Let me ask another question, to help me better understand your
> position.  What if GeoLocationML was already a widely supported
> document format?  Would you be any less in favour of defining a
> specific API?
>
>>. 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.
>
> Agreed, events are a huge value-add.
>
> But without the DOM, DOM events are just events (duh! 8-).  I see
> considerable value in the event flow model.  For example, one might
> consider defining a document to capture the state of the messaging
> system of the client device, with a hierarchy something like;
>
> Messaging
>  Incoming
>    SMS
>    Email-folder1
>    Email-folder2
>    IM-acct1
>    IM-acct2
>  Outgoing
>    SMS
>
> etc..
>
> I can see many scenarios where a script might be interested in
> registering for, say, any incoming message, which it can do so using
> DOM events, so long as the event fired from Incoming/SMS bubbles up to
> Incoming so it can be captured there.  Is that not appealing?  Would
> there be a simpler way to do this without the baggage of the full DOM
> event model?
>
> Mark.
>
>

Received on Monday, 9 June 2008 04:40:13 UTC