RE: DOM Dependency

I'm not seeing anything that says or indicates that we have to be compatible or consistent with the DOM event model, I understand why it may be desirable but there are server side JS folks that also should be able to use this API and we don't think forcing a model on them is the right way to go. The implementation should not show through the API.

-----Original Message-----
From: Ryan Sleevi [mailto:sleevi@google.com] 
Sent: Tuesday, February 26, 2013 10:58 AM
To: Anthony Nadalin
Cc: GALINDO Virginie; David Dahl; public-webcrypto@w3.org; Alex Russell
Subject: Re: DOM Dependency

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 22:35:22 UTC