Re: DOM Dependency

As a DOM neophyte, I find myself wondering what we really get from the DOM.

It seems like the major thing is DOM Events.  However, I wonder how relevant that spec really is.  Almost the entire DOM Events spec [1] is spent talking about complicated event propagation through a DOM hierarchy -- none of which is really relevant here.

DOM Events aren't necessary for asynchronous operation.  The Geolocation API is asynchronous gets along just fine using plain callbacks [2]. 

If the "event/task processing model" you're talking about is the "queue a task" language that appears throughout the spec, then I don't think that's really relevant to this conversation, since it's an implementation detail.

So it seems like it comes down to style.  Do we handle callbacks using the EventTarget methods, and pass them events with custom "result" values, or do we use custom callbacks to which the result is supplied directly?  For example:

var eventSuccess = function eventSuccess(myEvent) {
    // Do stuff with e.target.result == ciphertext
}
var op = window.crypto.encrypt(alg, key, buffer);
op.onsuccess = eventSuccess;

---or---

var callbackSuccess = function callbackSuccess(ciphertext) {
    // Do stuff with ciphertext
}
window.crypto.encrypt(alg, key, buffer, callbackSuccess);

The latter actually seems marginally more developer friendly for "one-shot" usage.

One might argue that using custom callbacks would be even cleaner as an API, since you could define argument types in WebIDL instead of all the fussing with what e.target.result is in the current spec.  Instead of saying "For a key import operation, e.target.result is a Key, or maybe a KeyPair", you could specify "callback KeyImportCallback(Key result)". 

Maybe I'm missing something.  Are we getting something from DOM Events than syntax consistency?  Are there other DOM features besides Events that we need?
  
--Richard


[1] http://www.w3.org/TR/domcore/#events
[2] http://www.w3.org/TR/geolocation-API/




On Feb 26, 2013, at 1:57 PM, Ryan Sleevi <sleevi@google.com> wrote:

> In order to remove that dependency, you need to rewrite the spec to
> demonstrate an asynchronous interface without using events, as well as
> define an event/task processing model that is wholly consistent with
> the existing DOM.
> 
> That is the minimum requirement to removing the dependency, and such a
> significant change would require a lot of review and discussion, and
> it would have to be demonstrated that such a rewrite does not create a
> web-developer-hostile API.
> 
> On Tue, Feb 26, 2013 at 10:49 AM, Anthony Nadalin <tonynad@microsoft.com> wrote:
>> so in order to have a proposal we have to have an issue, not sure issue 10
>> captures all the points here. I will look over issue 10 and see. The
>> technical contribution would come in the form of spec updates to remove DOM
>> dependency, right now there is a explicit statement in the API that DOM MUST
>> be supported, that would be removed.
>> 
>> Sent from Windows Mail
>> 
>> From: GALINDO Virginie
>> Sent: February 26, 2013 10:39 AM
>> To: Ryan Sleevi
>> CC: David Dahl, public-webcrypto@w3.org, Anthony Nadalin, Alex Russell
>> Subject: RE: DOM Dependency
>> 
>> Ryan,
>> 
>>> Are you suggesting that non-browser use cases are in scope, until
>>> established otherwise, or that they're out of
>>> scope, until proposals emerge that make them in scope?
>> 
>> I think that none of your proposal fit with my mail :).
>> 
>> I am not trying to decide if it is in or out of scope of the charter as I
>> think it has been treated as a grey zone. I remind that we raised the
>> issue-10 about "non-browser environment" 10 months ago, and no one said that
>> "non-browser environment" was out of scope - which means probably that it
>> was not that clear in the charter.
>> 
>> My mail is a call for technical contribution (to replace charter
>> interpretation never ending discussion that I see coming). If there is no
>> contribution that the WG and editors feel reasonable, we will not address
>> the non-browser environment.
>> 
>> Does it clarify ?
>> 
>> Regards,
>> Virginie
>> 
>> 
>> -----Original Message-----
>> From: Ryan Sleevi [mailto:sleevi@google.com]
>> Sent: mardi 26 février 2013 19:21
>> To: GALINDO Virginie
>> Cc: David Dahl; public-webcrypto@w3.org; Anthony Nadalin; Alex Russell
>> Subject: Re: DOM Dependency
>> 
>> On Tue, Feb 26, 2013 at 10:17 AM, GALINDO Virginie
>> <Virginie.GALINDO@gemalto.com> wrote:
>>> Dear all,
>>> 
>>> It seems to me that the ISSUE-10 describes the request from Anthony :
>>> http://www.w3.org/2012/webcrypto/track/issues/10 This issue was raised at
>>> last summer F2F meeting in Santa Clara, and we said that it would be nice to
>>> make sure we are addressing any environment, browser based or not
>>> browser-based. Unfortunately, we did not have any proposal to formally
>>> review the spec, with that constraint.
>>> 
>>> Personally I don't remember non-browser framework were considered as out
>>> of scope during our discussion in Santa Clara and on the other hand, when
>>> the charter was designed, this case was not mentioned -which could explain
>>> why the webapp case is so popular in it.  We can argue hours about the
>>> charter interpretation but I think that we should start with a pragmatic
>>> approach to that.
>>> 
>>> Is there any reasonable technical solution to cope with that constraint,
>>> that can be managed in a timeframe which fits with our deliverable roadmap ?
>>> Any proposal from the WG participants ?
>> 
>> Hi Virginie,
>> 
>> I'm not sure I understand this question you're asking.
>> 
>> Are you suggesting that non-browser use cases are in scope, until
>> established otherwise, or that they're out of scope, until proposals emerge
>> that make them in scope?
>> 
>>> 
>>> Regards,
>>> Virginie
>>> 
>>> 
>>> 
>>> -----Original Message-----
>>> From: David Dahl [mailto:ddahl@mozilla.com]
>>> Sent: mercredi 20 février 2013 07:50
>>> To: Anthony Nadalin
>>> Cc: public-webcrypto@w3.org; Alex Russell; Ryan Sleevi
>>> Subject: Re: DOM Dependency
>>> 
>>> I am trying to imagine node.js mocking/implementing (properly) the
>>> EventTarget interface. That does not seem like it will work too well.
>>> 
>>> That being said, the WorkerCrypto interface might work better in a
>>> non-browser environment as a worker will not be as tied to the DOM.
>>> 
>>> Regards,
>>> 
>>> David
>>> 
>>> ----- Original Message -----
>>> From: "Anthony Nadalin" <tonynad@microsoft.com>
>>> To: "Ryan Sleevi" <sleevi@google.com>
>>> Cc: public-webcrypto@w3.org, "Alex Russell" <slightlyoff@google.com>
>>> Sent: Tuesday, February 19, 2013 10:22:20 PM
>>> Subject: RE: DOM Dependency
>>> 
>>> It has been discussed many times in this WG, the browser is not the only
>>> target for the APIs, stand-alone and server side are also targets, the
>>> specification should not have a dependency on DOM and a bug should be opened
>>> to resolve this.
>>> 
>>> -----Original Message-----
>>> From: Ryan Sleevi [mailto:sleevi@google.com]
>>> Sent: Tuesday, February 19, 2013 2:30 PM
>>> To: Anthony Nadalin
>>> Cc: public-webcrypto@w3.org; Alex Russell
>>> Subject: Re: DOM Dependency
>>> 
>>> On Tue, Feb 19, 2013 at 2:23 PM, Anthony Nadalin <tonynad@microsoft.com>
>>> wrote:
>>>> And also tasked for standalone environments so we should not have
>>>> this dependency as this is not a JS dependency
>>> 
>>> Can you point that out in the charter?
>>> 
>>> We're talking about the same dependency found in HTML - namely, the notion
>>> of a sane event model.
>>> 
>>> I'd be curious to see how you would propose an asynchronous API without
>>> events and without re-inventing events through some specification-specific
>>> dialect.
>>> 
>>> The phrase "Web Application" appears nine times in our charter, so surely
>>> this is not being seen as some new requirement. It's been this way since the
>>> start.
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>

Received on Tuesday, 26 February 2013 23:41:22 UTC