Re: Proposal for a Permissions API

2014-09-03 Thread Mounir Lamouri
On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote: I'm generally supportive of this direction. I'm not sure that that the PermissionStatus thing is needed. For example in order to support bluetooth is might be better to make the call look like: permissions.has(bluetooth,

Re: =[xhr]

2014-09-03 Thread Greeves, Nick
I would like to emphasise the detrimental effect that the proposed experimentation would have on a large number of sites across Chemistry research and education that would mysteriously stop working when users (automatically) upgraded their browsers and JSmol ceased to function. JSmol is used

Re: =[xhr]

2014-09-03 Thread François REMY
Yes, sure, a lot of it can be done asynchronously. And I do that as much as possible. But I suggest there are times where synchronous transfer is both appropriate and necessary. The case in point is 50 levels deep in the stack of function calls when a new Java class is needed. This statement is

Re: {Spam?} Re: [xhr]

2014-09-03 Thread Arthur Barstow
On 9/2/14 9:10 PM, Brendan Eich wrote: cha...@yandex-team.ru wrote: Sorry. As with showModalDialog() we would really like to make this feature disappear. I realize this makes some forms of code generation harder, but hopefully you can find a way around that in time. Perhaps we should

Re: {Spam?} Re: [xhr]

2014-09-03 Thread Robert Hanson
That I think what is unclear from the writing of the warning are two things: 1) It *appears *to be part of the spec. (The parts before say they are non-normative, but this section does not.) And it uses the word must -- implying that it is a requirement, not a recommendation. 2) Perhaps it is

Re: =[xhr]

2014-09-03 Thread Olli Pettay
On 09/03/2014 12:10 PM, Greeves, Nick wrote: I would like to emphasise the detrimental effect that the proposed experimentation would have on a large number of sites across Chemistry research and education that would mysteriously stop working when users (automatically) upgraded their browsers

Re: =[xhr]

2014-09-03 Thread David Rajchenbach-Teller
Q1) No, there is no immediate alternative at the moment, nor is there one planned. One of the reasons for this proposed change to the semantics of XHR is to stop hiding asynchronous behavior behind a synchronous implementation that cannot be quite implemented in a satisfactory manner. Q2) The

Re: =[xhr]

2014-09-03 Thread Greeves, Nick
Olli, Thanks for the reassurance and your comment about nightly builds makes a lot of sense. Users of those would expect things to break. All the best Nick -- 3D Organic Animations http://www.chemtube3d.com Tel: +44 (0)151-794-3506 (3500 secretary) On 3 Sep 2014, at 13:57, Olli

Re: =[xhr]

2014-09-03 Thread Brendan Eich
David Rajchenbach-Teller wrote: it would require changes to Java2Script. Big changes -- CPS conversion, compiling with continuations. This would require identifying all the potential blocking points. It's not clear anyone will do it, even if it is feasible (thanks to Java's static types and

Re: =[xhr]

2014-09-03 Thread Brendan Eich
David Rajchenbach-Teller wrote: Clearly, it would require big changes, although compiling to return Promise and using Task.js + yield at call sites would probably be much simpler than CPS conversion. All call sites, every last Java method = JS function call? That means every single function

Re: Proposal for a Permissions API

2014-09-03 Thread Kostiainen, Anssi
On 02 Sep 2014, at 16:51, Mounir Lamouri mou...@lamouri.fr wrote: TL;DR: Permissions API would be a single entry point for a web page to check if using API /foo/ would prompt, succeed or fail. You can find the chromium.org design document in [1]. [...] Thanks for the strawman proposal. I

Re: =[xhr]

2014-09-03 Thread David Rajchenbach-Teller
On 03/09/14 17:27, Brendan Eich wrote: David Rajchenbach-Teller wrote: it would require changes to Java2Script. Big changes -- CPS conversion, compiling with continuations. Clearly, it would require big changes, although compiling to return Promise and using Task.js + yield at call sites

Re: {Spam?} Re: [xhr]

2014-09-03 Thread Ian Hickson
On Tue, 2 Sep 2014, Brendan Eich wrote: Also (I am a WHATWG cofounder) it is overreach to promise obsolescence on any timeline on the Web. Robert should not worry about real browser implementors breaking content by removing sync XHR -- to do so would be to lose market share. In this

Re: {Spam?} Re: [xhr]

2014-09-03 Thread Anne van Kesteren
On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: Hear hear. Indeed, a large part of moving to a living standard model is all about maintaining the agility to respond to changes to avoid having to make this very kind of assertion. See

Re: {Spam?} Re: [xhr]

2014-09-03 Thread Arthur Barstow
On 9/3/14 8:25 AM, Robert Hanson wrote: That I think what is unclear from the writing of the warning are two things: Per the specs' Participate boilerplate, perhaps you should file a bug (^1). -Thanks, AB ^1 https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWGcomponent=XHR

Re: IndieUI Teleconference Agenda; 3 September at 21:00Z for 60 minutes

2014-09-03 Thread James Craig
Regrets. I've had another responsibility arise that will prevent me from attending today's conference call. On Sep 2, 2014, at 1:00 PM, Janina Sajka jan...@rednote.net wrote: As before I'm cross-posting this IndieUI agenda As part of IndieUI's continuing open invitation continuing our

Re: IndieUI Teleconference Agenda; 3 September at 21:00Z for 60 minutes

2014-09-03 Thread Janina Sajka
My probable regrets as well due to a one-time scheduling conflict. Michael, given that James and Jason are also both unavailable, I leave it to your discretion whether to cancell today's call. Janina Janina Sajka writes: As before I'm cross-posting this IndieUI agenda As part of IndieUI's

Re: IndieUI Teleconference Agenda; 3 September at 21:00Z for 60 minutes

2014-09-03 Thread Richard Schwerdtfeger
regrets for tonight. Rich Schwerdtfeger From: Janina Sajka jan...@rednote.net To: public-indie...@w3.org Cc: public-editing...@w3.org public-editing...@w3.org, public-webapps@w3.org public-webapps@w3.org Date: 09/03/2014 01:59 PM Subject:Re: IndieUI

Re: {Spam?} Re: [xhr]

2014-09-03 Thread Ian Hickson
On Wed, 3 Sep 2014, Anne van Kesteren wrote: On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: Hear hear. Indeed, a large part of moving to a living standard model is all about maintaining the agility to respond to changes to avoid having to make this very kind of assertion.

Re: {Spam?} Re: [xhr]

2014-09-03 Thread Glenn Maynard
(Branden, your mails keep getting {Spam?} put in the header, which means every time you post, you create a new thread for Gmail users. I guess it's the list software to blame for changing subject lines, but it's making a mess of this thread...) On Wed, Sep 3, 2014 at 12:49 PM, Anne van Kesteren

Re: {Spam?} Re: [xhr]

2014-09-03 Thread Tab Atkins Jr.
On Wed, Sep 3, 2014 at 12:45 PM, Glenn Maynard gl...@zewt.org wrote: My only issue is the wording: it doesn't make sense to have normative language saying you must not use this feature. This should be a non-normative note warning that this shouldn't be used, not a normative requirement

Re: {Spam?} Re: [xhr]

2014-09-03 Thread Jonas Sicking
On Wed, Sep 3, 2014 at 10:49 AM, Anne van Kesteren ann...@annevk.nl wrote: On Wed, Sep 3, 2014 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: Hear hear. Indeed, a large part of moving to a living standard model is all about maintaining the agility to respond to changes to avoid having to make

Re: {Spam?} Re: [xhr]

2014-09-03 Thread Jonas Sicking
On Wed, Sep 3, 2014 at 2:01 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: On Wed, Sep 3, 2014 at 12:45 PM, Glenn Maynard gl...@zewt.org wrote: My only issue is the wording: it doesn't make sense to have normative language saying you must not use this feature. This should be a non-normative

[No quorum] Re: IndieUI Teleconference Agenda; 3 September at 21:00Z for 60 minutes

2014-09-03 Thread Michael Cooper
Only Takeshi and I joined the call, with Jason for a brief hi. This is not enough quorum to discuss anything meaningful so we ended the call after 15 minutes. Michael On 02/09/2014 4:00 PM, Janina Sajka wrote: As before I'm cross-posting this IndieUI agenda As part of IndieUI's continuing

Re: File API: reading a Blob

2014-09-03 Thread Aymeric Vitte
Sorry to interfer then but your discussion with Arun seems to have no point if streams are there. But some points I mentioned have, whether it's really linked to the initial subject or not. The fact is that most of the W3C groups impacted by streams (File, indexedDB, MSE, WebRTC, WebCrypto,

Re: File API: reading a Blob

2014-09-03 Thread Arun Ranganathan
On Aug 11, 2014, at 7:24 AM, Anne van Kesteren ann...@annevk.nl wrote: Other than “chunks of bytes” which needs some normative backbone, is the basic abstract model what you had in mind? If so, that might be worth getting into File APi and calling it done, because that’s a reusable

Re: File API: reading a Blob

2014-09-03 Thread Arun Ranganathan
On Sep 3, 2014, at 6:02 PM, Aymeric Vitte vitteayme...@gmail.com wrote: The fact is that most of the W3C groups impacted by streams (File, indexedDB, MSE, WebRTC, WebCrypto, Workers, XHR, WebSockets, Media Stream, etc, I must forget a lot here) seem not to care a lot about it and maybe