[whatwg] Media Stream API: What is the intended behaviour for undefined mandatory arguments?
Hi Ian and the rest of the list, We are having a bit of discussion regarding the correct behaviour when mandatory arguments are undefined, see this webkit bug for history: https://bugs.webkit.org/show_bug.cgi?id=60622 Could we have some clarification for the below cases, please: var u; var n = null; // Should throw since u is undefined or just abort? navigator.webkitGetUserMedia(audio, u); // Will not throw but will abort. navigator.webkitGetUserMedia(audio, n); // Should throw because we are expecting at least two arguments. navigator.webkitGetUserMedia(audio); Thanks in advance, Tommy -- Tommy Widenflycht, Senior Software Engineer Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden Org. nr. 556656-6880 This email may be confidential or privileged. If you received this communication by mistake, please don't forward it to anyone else, please erase all copies and attachments, and please let me know that it went to the wrong person. Thanks! And yes, I have to include this message in every outgoing email according to EU law.
[whatwg] Enhancement request: change EventSource to allow cross-domain access
Can EventSource be enhanced to support cross-domain requests via Access-Control-Allow-Origin header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests. I filed a request with WebKit bugzilla and they suggested to send it to you: https://bugs.webkit.org/show_bug.cgi?id=61862 The rationale and use cases are exactly the same as for XHR: it can be useful to access different domains. Is support for EventSource cross domains planned at all? It is supposedly one of the most requested features, but I do not know how it is tracked. Thanks
[whatwg] Application Cache
Dear Friends of HTML5, i think i have the topic back on the list in my mind. I know already two workarounds. 1) Whitelisting the index file (having the manifest) - create a splash screen to walk through. Whitelist the (previous) master file like a normal network resource there. For a CMS with scripts, css and images from Disk, create a example.com/cached-version-start.html with the manifest. Whitelist the master, where you wanted the manifest before. You can go through a door or a splash screen for a half-cached-site, where scripts and styles with long loading times come from disk. 2) Adding files to the cache. The Video HTML5 Wow and the How demonstrates the FileAPI. Ok, with this API and some Storage i can write down all the pages received. This will be what i will use, if i can´t bring the additions to the cache. The two are no excuses for letting the few functions for the cache out of the cache. The media there is already grouped as normal pages and media and behave like. You don´t have to do much more working around with the file api, to reach the implementation of the cache, ok, you got to do the same work. But only once, to add the functions. FileAPI users would have to write a cache-lib or programm that every application again. I think the cache would benefit from it´s expansion. I think the Manifest Container is a good Spot. But i prefer to add Classes for the three List containers, extending the Vector and the Map a little. This seems to be better programming for me, but i could change mind and say the operations working from the manifest on, using the vector and map functions and elements inside to handle that, is overviewabler (seems, or? now i mean second is better, using manifest). My fault, that i haven´t made it yet to the IDL and script binding to the functions. Sorry. I´ll be motivated to beat you soon, ok? Greetings Edward Gerhold
[whatwg] Pain with the Headers in webkit/appcache.
Me again.. Won´t continue writing down every step. But my next look, i´ll be motivated now, tells me one thing: Create a _new header_ with the Interfaces, and work on the manifest structure. This is what the rest of the files in webkit/appcache do with all the data. I shouldn´t write the functions into class Manifest. Simply work with the existing Manifest and the Operations get the Lists and do something with. How to read and write the Page data, that is written in the code in the other Files. The class Manifest is bound to the manifest parser file. I could call it manifest_manipulator or think again about it. But i think, being better readable and fitting better in webkit, i shouldn´t write into manifest_parser. Is it easier to add a new file to such a branch or to patch an existing? Looks it better to seperate the new functions from the manifest, even if they belong, too? Good, i´ll find out. Uhm, and another workaround for the update function in a CMS is to let the CMS generate the manifest again with new version number and the additional or removed files. Make sure to document, that people using your cached site, would sometimes rather check chrome://appcache-internals and delete, than waiting for any update to be sure, to check out the latest. But that is only working around the statics of the application cache. Ok, i´m motivated again. Inform you in around 6 weeks, if you like to think about the better cache, just do so. It´ll make the world look better. My aim is to read some hours now, that will be self-explanatory for me then. Greeting Edward Gerhold
Re: [whatwg] Media Stream API: What is the intended behaviour for undefined mandatory arguments?
2011/6/1 Tommy Widenflycht (ᛏᚮᛘᛘᚤ) tom...@google.com: Hi Ian and the rest of the list, We are having a bit of discussion regarding the correct behaviour when mandatory arguments are undefined, see this webkit bug for history: https://bugs.webkit.org/show_bug.cgi?id=60622 Could we have some clarification for the below cases, please: var u; var n = null; // Should throw since u is undefined or just abort? navigator.webkitGetUserMedia(audio, u); // Will not throw but will abort. navigator.webkitGetUserMedia(audio, n); // Should throw because we are expecting at least two arguments. navigator.webkitGetUserMedia(audio); This is defined by WebIDL, although somewhat complicatedly: http://dev.w3.org/2006/webapi/WebIDL/#es-operations The key is the two steps Initialize S to the effective overload set . . . and Set S to the result of passing S and arg0..n−1 to the overload resolution algorithm. Basically, that means Let S be the set of all the methods with this name on this object, then remove from the set any methods that can't accept the provided arguments. I *think* the overload resolution algorithm specifies that if too few or too many arguments are passed, the method is rejected. Then you fall through to If S is empty, throw a TypeError, so that's apparently the specified behavior. But WebIDL always confuses me, so I wouldn't swear to it. But there's an open issue that says Need to test how implementations actually behave when passed too few or too many arguments. So I wouldn't assume the standard is right. Maybe data would be useful on how different browsers behave here -- although I suspect that it will vary greatly from method to method. I can tell you from experience that Gecko throws if you pass fewer than three arguments to document.execCommand(). It makes sense to me -- if we want the API to not throw if the argument is omitted, why isn't the argument optional?
Re: [whatwg] Enhancement request: change EventSource to allow cross-domain access
On Wed, Jun 1, 2011 at 11:23 AM, ilya goberman gober...@msn.com wrote: Can EventSource be enhanced to support cross-domain requests via Access-Control-Allow-Origin header, just like it is already done for XHR? See http://en.wikipedia.org/wiki/XMLHttpRequest#Cross-domain_requests. I filed a request with WebKit bugzilla and they suggested to send it to you: https://bugs.webkit.org/show_bug.cgi?id=61862 The rationale and use cases are exactly the same as for XHR: it can be useful to access different domains. Is support for EventSource cross domains planned at all? It is supposedly one of the most requested features, but I do not know how it is tracked. I absolutely think we should do this. I was in fact quite surprised to find that this wasn't already the case. Getting event streams from other sites seems like a prime use case for EventSource. We should probably consider adding the ability to specify if you want the request to happen with or without credentials (and default to the safe option which is without credentials). / Jonas
Re: [whatwg] Media Stream API: What is the intended behaviour for undefined mandatory arguments?
Tommy Widenflycht (ᛏᚮᛘᛘᚤ): Could we have some clarification for the below cases, please: var u; var n = null; // Should throw since u is undefined or just abort? navigator.webkitGetUserMedia(audio, u); I don’t think Ian has made changes to the spec yet regarding interface types not including null unless explicit made nullable. So let me assume for now that the spec says void getUserMedia (in DOMString options, in NavigatorUserMediaSuccessCallback? successCallback, in optional NavigatorUserMediaErrorCallback? errorCallback); which I think is supported by the prose describing the method. null therefore is a value that can be passed to the two callback methods. Per Web IDL at the moment, when there is no overloading, the types of values passed to a method do not determine whether the call is to that one unoverloaded method or not; it is assumed that you are calling that method. Therefore, each argument will just get converted according to the rules in http://dev.w3.org/2006/webapi/WebIDL/#es-types. This is a nullable type, so we look at http://dev.w3.org/cvsweb/~checkout~/2006/webapi/WebIDL/Overview.html?rev=1.292;content-type=text%2Fhtml#es-nullable-type (as the spec looked earlier today). Here, any value other than null is converted according to the inner type. There is a bug here: those rules should also explicitly consider undefined as a JS value that is converted to an IDL null value. Otherwise you would end up with a TypeError being thrown here, and I don’t think that’s what you want. It’s also inconsistent with what the spec used to say before I made the recent change where null was removed from interface types. I’ve just fixed this bug now: http://dev.w3.org/2006/webapi/WebIDL/#es-nullable-type So if you pass undefined for successCallback it will be treated as null. // Will not throw but will abort. navigator.webkitGetUserMedia(audio, n); Right. // Should throw because we are expecting at least two arguments. navigator.webkitGetUserMedia(audio); Actually this should behave as if you called getUserMedia(audio, undefined). This is because of the different behaviour for overloading I mentioned above; when there is overloading, you will get a TypeError thrown if the number of actual arguments doesn’t match the expected number of formal arguments for one of the overloads. This difference in behaviour is sucky, and I’ll be looking at improving this in Web IDL soon. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] Media Stream API: What is the intended behaviour for undefined mandatory arguments?
Aryeh Gregor: But there's an open issue that says Need to test how implementations actually behave when passed too few or too many arguments. So I wouldn't assume the standard is right. Maybe data would be useful on how different browsers behave here -- although I suspect that it will vary greatly from method to method. I can tell you from experience that Gecko throws if you pass fewer than three arguments to document.execCommand(). It makes sense to me -- if we want the API to not throw if the argument is omitted, why isn't the argument optional? It could be that the default coercion from undefined is acceptable, be that throwing a TypeError, or being converted to false, etc. Some months ago, after meeting with the TC39 folks, we came out with the proposal to make Web IDL be relaxed, i.e. assume undefined for missing arguments and allow additional arguments to be ignored, which I mailed to public-script-coord, but I didn’t see any pushback on that. Since this is something that I want to resolve soon, it might be worth my bringing it up on the list again. At the very least, though, I want the behaviour of non-overloaded and overloaded operations to be the same. The current behaviour is confusing. -- Cameron McCormack ≝ http://mcc.id.au/
