Re: An import statement for Web IDL
On Mon, 29 Jun 2009, Maciej Stachowiak wrote: It would be nice if we could find a way to make things more rigorous with a mechanism that's convenient to both spec writers and browser developers. On possibility: we could consistently use modules and have a way to import by module name, a la Java. Specs could import other modules wholesale with prose or an IDL fragment at the top of the document. We could recommend that non-W3C spec specs should use reverse DNS style module prefixes to avoid the possibility of collision. This makes the name binding more rigorous than filename-based includes and should not overly get in the way of implementations or specs. I would rather have just one module for all of the Web platform, since at the end of the day there's only one namespace in JS. However, I do think it'd be nice to have tools to help us check the IDL. Could we have a tool that just scans the textContent out of pre elements with class=idl, or something? We could give it the URLs of all the specs being developed, and every hour or day or something it could try to fetch all the specs, check that the IDLs still make sense, and if anything bad happens, post an e-mail to some list we all subscribe to. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: File API Feedback
On Mon, Jun 29, 2009 at 11:14 AM, Arun Ranganathana...@mozilla.com wrote: Garrett, Thanks for taking the time to review this. Garrett Smith wrote: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml Why does the URI contain the date 2006? It certainly is confusing, but the '2006' persists as an artifact of the CVS repository that I'm using to work on my editor's draft. When ready, it should be published to a URL that is more intuitive (and follow how W3C usually publishes things). In the latest public version there is no getAsDataURI, nor a getDataAsURL. I don't see url in the page anywhere. This is added to the editor's draft. As written, it seems like a synchronous method call. I recall discussions where a few problems with synchronous design mentioned and an asynchronous call was deemed the better approach. Correct -- that is why the editor's draft reflects that discussion by formulating useful APIs as asynchronous ones. In the old dev uri, I see the kludge:- void getAsDataURI(in FileAsText callback, [Optional] in FileErrorCallback errorCallback); Can I ask why you've chosen to have the callee invoking callback methods? What about extensibility? To add a progress event, you'd have to pass in an optional progress callback, update the entire API. Then a complete callback? The callback arguments ought to be designed as events. The calling context first subscribes to events, then requests file object to perform the read. DOM Events is the event API that we have and an event API ought to be used. Callback dom properties would be another option to consider in tandem, e.g. myFile.onprogress. Callbacks are used so that these APIs can behave asynchronously. As drafted now, I agree that it is a kludge because the use the error callback is made optional. I no longer think it should be optional, and implementations MUST call one or the other. The 'null' File data string (or a null FileList) is not as instructive as simply having an error callback. That design limits the number of callbacks to one. That one callback can only be added in the invocation to read. Instead, allow multiple callbacks to be added with the DOM Events API: // Add some callbacks fileObject.addEventListener(complete, readComplete, false); fileObject.addEventListener(error, readError, false); fileObject.addEventListener(success, readSuccess, false); fileObject.getDataAsText(); An asynchronous file read is like an asynchronous XHR, in a way. However, I disagree that an event model is necessary for *this* specification. Certainly, ProgressEvents can be used with *other* aspects of the platform, in conjunction with the File API. They are not necessary for asynchronous file data accessors. Lets back up and consider why one might want Events, or why Events make sense. Events decouple the call to read from the notification that the object is done reading. That allows the File object, read method, and its events, to evolve over time. Decoupling messaging (callbacks) from commands (behavior) enables independent and concurrently existing views (interfaces) of the API. The two ways to implement events are: 1) DOM Events - works and is widely implemented in major browsers. 2) DOM Event handler properties work and even more widely implemented and used AISB, Events decouple the read from the notification. N callbacks can be attached, removed, at any time, and the reading can be wrapped in code that exists elsewhere. This makes for writing cleaner implementation code. Inelegant APIs proliferate bad design. The current browser APIs followed by the burgeoning Ajax libraries might be considered an example of such causality. Progress-type Events are useful because the API is asynchronous. What if reading the file times out? If an entire directory is uploaded, as in the Picasa-style example, when does the success callback fire? 1) after all files in stress are successfully read 2) upon completion of each file When reading one large file (a movie, for example), how will the program provide notification of progress of the upload? Garrett
Re: Web IDL syntax
Cameron McCormack:
Following are my half baked proposals.
I’ve now baked all of these proposals into the spec, except for the one
about allowing multiple module levels with a module declaration (i.e.,
‘module a::b::c’).
* Made ‘in’ optional
http://dev.w3.org/2006/webapi/WebIDL/#idl-operations
* Dropped [ImplementedOn] in favour of an ‘implements’ statement
http://dev.w3.org/2006/webapi/WebIDL/#idl-implements-statements
* Changed Object, TRUE and FALSE to lowercase
http://dev.w3.org/2006/webapi/WebIDL/#idl-grammar
* Dropped [Optional] and [Variadic] in favour of ‘optional’ and ‘...’
http://dev.w3.org/2006/webapi/WebIDL/#dfn-variadic-operation
http://dev.w3.org/2006/webapi/WebIDL/#dfn-optional-argument
* Dropped [ExceptionConsts] in favour of allowing constants to be
defined directly on exceptions
http://dev.w3.org/2006/webapi/WebIDL/#idl-exceptions
* Replaced [Callable], [IndexGetter], [Stringifies], etc. with real
IDL syntax
http://dev.w3.org/2006/webapi/WebIDL/#idl-special-operations
* Changed [NameGetter=OverrideBuiltins] into [OverrideBuiltins]
http://dev.w3.org/2006/webapi/WebIDL/#OverrideBuiltins
* Renamed DOMString to string:
http://dev.w3.org/2006/webapi/WebIDL/#idl-string
If you’re writing a dependent spec and need help changing your IDL to
match the changes I’ve made, let me know.
Two (perhaps more controversial? or at least undiscussed) changes I’ve
made with this commit are to replace boxed valuetypes with the concept
of nullable types, like there are in C#, and to remove null from the set
of values string (née DOMString) can take.
http://dev.w3.org/2006/webapi/WebIDL/#idl-nullable-type
http://dev.w3.org/2006/webapi/WebIDL/#idl-string
A while ago, there was some discussion about whether null should indeed
be a member of that type. Jonas made a comment at one point about it
being strange to have null be a valid DOMString value while having the
default conversion behaviour being that a JS null value was treated as
the string null. So now authors of IDL will need to make a conscious
decision about whether null is a valid value for attributes and
operation arguments that take strings. The type ‘string’ doesn’t allow
null, while the type ‘string?’ does:
interface X {
attribute string a;
[TreatNullAs=EmptyString] attribute string b;
attribute string? c;
[TreatUndefinedAs=EmptyString] attribute string d;
[TreatUndefinedAs=Null] attribute string? e;
};
x.a = null; // assigns null
x.a = undefined; // assigns undefined
x.b = null; // assigns
x.c = null; // assigns null
x.c = undefined; // assigns undefined
x.d = undefined; // assigns
x.e = undefined; // assigns null
(Oh yeah, I renamed [Null] and [Undefined] to [TreatNullAs] and
[TreatUndefinedAs] to give them more descriptive names.)
The issue of whether these are the right defaults is still open. I
haven’t had time to finish detailed testing to see whether defaulting to
stringification is the best.
http://dev.w3.org/2006/webapi/WebIDL/#TreatNullAs
http://dev.w3.org/2006/webapi/WebIDL/#TreatUndefinedAs
http://dev.w3.org/2006/webapi/WebIDL/#es-string
http://dev.w3.org/2006/webapi/WebIDL/#es-nullable-type
Cameron McCormack:
An alternative would be to reverse the omission of methods, so that
“getter” on an operation would always have both the getter.
Ian Hickson:
I prefer omittable because it would mean I wouldn't have to say and the
setter works like this other method in prose all the time.
I’ve done it this way.
http://dev.w3.org/2006/webapi/WebIDL/#idl-special-operations
If we are breaking syntax, then it seems more compelling to make
“DOMString” be “string”.
Maybe we could drop the “in” keyword. Seems better to stick with
plain “in” arguments, for compatibility across language bindings,
than to also allow “out” and “inout” ones.
I'd vote for not changing these, because we already have a lot of IDL out
there and it would be a pain to fix it all.
I tried changing DOMString to string and liked the look of it, so I’m
leaving it in for now. There isn’t much Web IDL content out there yet,
so I think we’re still at a stage where it’s manageable to change. If
you need help changing this (and the other syntax changes) in HTML 5,
let me know and I’ll supply a patch against
http://svn.whatwg.org/webapps/source.
Regarding 'implements' (heycam and I talked about this on IRC recently;
I just wanted to get some notes down on the record):
There are three use cases that need covering:
- inheritance (e.g. Node - Element - HTMLElement - HTMLAnchorElement)
- interfaces that are to be implemented by many other objects (e.g.
EventTarget)
- interfaces that are defined across multiple specs (e.g. Window,
WorkerUtils, HTMLBodyElement's attributes and methods being separated
from its deprecated attributes and methods)
The first is handled by ':',
Re: An import statement for Web IDL
On Jun 29, 2009, at 11:26 PM, Ian Hickson wrote: On Mon, 29 Jun 2009, Maciej Stachowiak wrote: It would be nice if we could find a way to make things more rigorous with a mechanism that's convenient to both spec writers and browser developers. On possibility: we could consistently use modules and have a way to import by module name, a la Java. Specs could import other modules wholesale with prose or an IDL fragment at the top of the document. We could recommend that non-W3C spec specs should use reverse DNS style module prefixes to avoid the possibility of collision. This makes the name binding more rigorous than filename-based includes and should not overly get in the way of implementations or specs. I would rather have just one module for all of the Web platform, since at the end of the day there's only one namespace in JS. If I were designing things from scratch, I would want to take this approach. However, the DOM specs already have their own module names and I don't think it's worth changing them. Reserving one particular module for all new W3C specifications seems reasonable, but I'm not sure it's better than one per spec. The point of using modules for this at all is to avoid non-W3C specifications accidentally or intentionally clashing with the names, though on further consideration, it seems like this would cause problems However, I do think it'd be nice to have tools to help us check the IDL. Could we have a tool that just scans the textContent out of pre elements with class=idl, or something? We could give it the URLs of all the specs being developed, and every hour or day or something it could try to fetch all the specs, check that the IDLs still make sense, and if anything bad happens, post an e-mail to some list we all subscribe to. Something like that seems like a good idea. Regards, Maciej
Re: [widgets] PC LC comments on I18N/L10N
Hi Marcos, thanks for your effort. See below for specific points. (Marked accordingly, see end of this e-mail for the legend.) On 29.6.2009 13.30, ext Marcos Caceres marc...@opera.com wrote: Hi Jere, Fixes and some questions below. I got stuck on your last point, can you please clarify it or suggest more clearly what you want me to do there? Sure, see inline below. Right. I've moved everything and renamed examples Localization examples. This would make the material flow better and have all the concepts defined before they are used. I will need you to check this before we republish. Is that OK? Also, the whole of Section 7 should actually appear right before the processing steps (i.e., after the current Section 8). I moved everything as you suggested. /JK1/ OK, I've checked it and I think it is now easier to find all the relevant stuff. However, the Localization guidelines section (now 8.1) is marked as non-normative, but I think it should be as normative as 8.2 and 8.3. Especially since there is some CC behaviour described. The complex example refers to several files which really have the same purpose. I think they should also have the same name, otherwise they cannot be found by the same reference. That is, /locales/es/gatos.html should be called /locales/es/cats.html. Or is it intentional? Never is:) That is a left over mistake from when we had multiple configs. /JK2/ Looks like the third file in 8.4.2 is still labeled locales/es/gatos.html. Those cats are tough to manage! :-) This statement in the authoring guideline is puzzling: '[That is,] authors cannot simply put shared files into a language level folder, but need to put all files needed into the language level folder for the widget to work (for example, having a.gif in both /locales/zh-Hans/ folder and locales/zh).' Isn't this the opposite of what is supposed to happen in the fallback model? If the same a.gif is good for both zh-Hans and zh, it should be possible for the author to include it just once in /locales/zh. Yes, this is correct. If the user's language list includes 'zh-Hans', it will also include 'zh', as per Step 5. So a.gif will be found eventually. Right. /JK3/ So then, isn't the statement I quoted above actually incorrect? Authors *can* simply put files into a language level folder, so that duplicates of the exact same file are not needed. If they have the same name but the content is different, then that's OK too. (Meaning that a resource called 'a.gif' could be completely different for zh-hans-cn and zh, and what is ultimately retrieved depends on the UA locale.) One more way to put it is that if your UA locale is zh-hans-cn, and there is no 'locales/zh-hans-cn/a.gif', but there is a 'locales/zh/a.gif', then the latter would be found and used. If you agree with this reasoning, then I think the statement should be removed. Or am I misreading it somehow? This is actually pretty crucial to the working of the whole model, so it's important to determine that we do have the same understanding, and that the spec text doesn't lead readers up the garden path in any way. Priority is probably a bad term to use with regard to localized folders. I changed it to: [[ In the example below, assuming the widget's locale is zh-hans-cn: * The a.gif file in the zh-Hans-CN locale folder would be used instead of the a.gif file in the zh-Hans locale folder. * The b.gif file in the zh-Hans locale folder would be used instead of the b.gif file in the zh locale folder. * The c.gif in the zh locale folder would be used instead of the c.gif file root of the widget package. * The d.gif file would always be used from the root of the widget, as it is not associated with any locales and is hence available to all locales. ]] I think this now accurately explains what should happen, thanks. /4/ The xml:lang attribute Does the XML specification state that the values of xml:lang attributes must be unique across instances of the same element? No. If yes, it is probably redundant to repeat that in the context of all the elements in the configuration document. If not, the statement about uniqueness could still be factored out, for example to section 8.4, to avoid repetition. Although redundant, I think I will leave this as is. If it's still annoying, we can remove it in CR as it would be an editorial change and it would have no normative impact. Is that OK? Yes, that's OK. (I was just trying to eradicate duplicate text.) In the first example of Step 5, why would en and en-au be swapped around when decomposed? I was missing an en, which might have been causing confusion. Taking the first part of the example: en-us,en-au,fr,en Would become: en-us,en-au,fr,en And would normalize to: en-us,en,en-au Sorry, but that doesn't correspond to anything I see in the spec now... :-( Maybe my original comment was misdirected, but you kind of lost me there. _however_, during
Re: File API Feedback
On Mon, Jun 29, 2009 at 11:52 PM, Garrett Smithdhtmlkitc...@gmail.com wrote: Progress-type Events are useful because the API is asynchronous. What if reading the file times out? If an entire directory is uploaded, as in the Picasa-style example, when does the success callback fire? 1) after all files in stress are successfully read 2) upon completion of each file When reading one large file (a movie, for example), how will the program provide notification of progress of the upload? I think you might be misunderstanding the proposed API. The API simply allows reading files from the local file system (once the user has elected to grant the page access to a file). The proposed API is *not* for sending files to a server, for example in a Picasa-style app. It is expected that XMLHttpRequest Level 2 will provide that functionality. Since XMLHttpRequest will be used, you'll have access to the full range of features available in XMLHttpRequest Level 2, such as ability to monitor progress, error and success. So, the scope of the current File API draft is limited simply reading files from the local file system. With that in mind, do you still think it makes sense to have progress events and all the other events you are proposing? I agree that using events are more powerful since it allows us to fire an unlimited number of different events, and allows pages to register unlimited numbers of listeners to various events. However, what is the use case for all this power? I.e. what application would want to do this? The downside of having all the power and features of using events is that the syntax becomes more complex. So we should only do it if it provides features that people actually need. / Jonas
Re: File API Feedback
On 6/19/09 6:00 AM, timeless wrote: On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com wrote: Hixie, I think a Base64 representation of the file resource may be sufficient, particularly for the image use case (which is how it is used already). Can you flesh out why the new schema is a good idea? so. I have folders with 100-1000mb of pictures in them. If I decide that I want to upload them all (Picasa style), i'd expect it would take a very long time to convert each file name into a base64 url. File API should probably have some way to get only parts of the file. getAsXXX(long long offset, long long length). Then uploading huge files could be split and decoding video (or something like that) in JS might become possible. This is something we need for XHR too https://bugzilla.mozilla.org/show_bug.cgi?id=496533 -Olli
Re: Widgets PAG seeks feedback on Widget Updates spec
On Mon, Jun 29, 2009 at 10:46 PM, Robin Berjonro...@berjon.com wrote: Hi, sorry, I hadn't seen that this was also posted publicly. On Jun 29, 2009, at 20:23 , Arthur Barstow wrote: The current Widgets-update Specification http://dev.w3.org/2006/waf/widgets-updates/ contains in 12.3 a description on how a widget could update itself by a javascript calling the widget.update() method I wanted to know how important this feature is to the group and how likely it will be that it will find widespread use. The goal is to assess whether it is worthwhile to circumvent the patent also for this self-update feature, which will be a little bit harder than the circumvention for the rest of the Specification. My personal and non-legal opinion on this topic is that that feature simply does not exist. It is mentioned in an example which by definition is not normative (section 1 Conformance further notes Everything in this specification is normative except for diagrams, examples, notes and sections marked as informative and the section itself starts with This section is informative.) It is not defined by Widget Updates and it is not defined by Widget APIs and Events. Furthermore my understanding is that this is the only part of the specification that could possibly infringe Apple's patent, which means that the specification in fact doesn't since that feature is not a part of it (or any other). We can more than very easily drop the example, and in fact the entire section since it is entirely incorrect. The purpose of widget.update() is/was _not_ to update the widget in any meaningful way: From the spec ...an author can request that a widget asynchronously check if a widget has been updated [(i.e., that a new version of the widget package is available online)] via the widget.update() method, defined in the Widgets-API specification. This strategy also relies on the author having declared a update element in the widget configuration document, as it makes use of the URI to potentially retrieve an UDD and relay whether an update is available back to the instantiated Widget. **Actually performing the update is left to the discretion of the widget user agent.** In other words, it was/is a means to for a widget to ask the Widget User Agent if an update is available from the remote location addressed by the update element's href attribute (so, really it should have been called checkForUpdate() or updateInfo = new UpdateChecker(), which the example begins to elude to). As it says in the spec, _actually performing the update is left to the discretion of the widget user agent._ So, to try to be crystal clear, here is how I thought this would work wrt widget.update() when I created this thing (and more or less what is eluded to in the spec): 1. Widget is running. 2. At some point in time, widget calls widget.update(callBackFunction). (Note that this is just one of the three strategies for _checking for the availability of an update_ (no actual updating is performed) - other two strategies are handled exclusively by the widget user agent, see spec). 3. Iff an update element is declared in the widget's config doc, and has a valid href attribute, the Widget User Agent MAY check for changes in the update description document (using http responses AND checking the content of the UDD for changes). 4. If an update is available invoke callBackFunction with an object describing the update. 5. If no update is available, invoke callBackFunction with an object describing that no update is available. 6. Author notifies, via some modality (e.g., a sound, an alert, or some visual means left up to the author), that an update is or is not available for the widget. 7. The end user quits the widget. 8. The end user requests from the Widget User Agent to update the widget (if update is available). 9. The widget user agent downloads the updated package from the location identified by the description document. 10. The widget user agent checks authenticity of package. If everything is ok, then overrides the existing widget, but maintains preference data. User agent MAY notify the end user that the widget has been updated. 11. End-User restarts the widget. So, I don't what would be achieved by removing widget.update() as it doesn't actually do any updating. If anything, we need to redefine widget.update() to make it more useful and powerful. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: File API Feedback
On Tue, 30 Jun 2009, Olli Pettay wrote: File API should probably have some way to get only parts of the file. getAsXXX(long long offset, long long length). Then uploading huge files could be split and decoding video (or something like that) in JS might become possible. This is something we need for XHR too https://bugzilla.mozilla.org/show_bug.cgi?id=496533 I'd rather just have an API that lets you split a File into a sequenceFileData (where FileData is what File inherits from) of equally sized chunks, or something like that, than something that lets you get chunks out in particular forms. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[webstorage] deleting a database
Hi! The webstorage specification needs an API to delete a database, because there's no such way to do it currently. Something like deleteDatabase(name) would be good. And after calling it, all open transactions would be marked as invalid. The user agent could then delete the data on disk and do all the necessary clean up. Thank you. -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
[WebIDL] grammar in ABNF
Hi Cameron, Could we have the Web IDL grammar in ABNF? I think ABNF is quite well adopted on the market. Otherwise, I think we could have more formal description of the grammar used in the current Web IDL spec, since it is easy now to misunderstand it having the ABNF syntax used in other specs. Thanks. Kind regards, Marcin Marcin Hanclik ACCESS Systems Germany GmbH Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465 Mobile: +49-163-8290-646 E-Mail: marcin.hanc...@access-company.com Access Systems Germany GmbH Essener Strasse 5 | D-46047 Oberhausen HRB 13548 Amtsgericht Duisburg Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda www.access-company.com CONFIDENTIALITY NOTICE This e-mail and any attachments hereto may contain information that is privileged or confidential, and is intended for use only by the individual or entity to which it is addressed. Any disclosure, copying or distribution of the information by anyone else is strictly prohibited. If you have received this document in error, please notify us promptly by responding to this e-mail. Thank you.
Re: [widgets] Rule for Identifying the media type of a file
On Wed, Jun 10, 2009 at 5:21 PM, Anne van Kesterenann...@opera.com wrote: This has the same problem with file-extension requiring a leading dot and the table not having any. I've added these now. I've made sure all tables containing file names and extensions are more consistent. These include: * Reserved File Names Table * Default Icons Table * Default Start Files Table * Media Type Identification Table * File Identification Table These changes are all editorial. The prose also does not make it clear that the entries in the first column may be comma-separated (and can have leading spaces, to be pedantic). I've made it so there is only one file extension per row. That should remove the ambiguity. These changes are all editorial. Why not use audio/wav or audio/wave for WAVE files? I could not find a formal IANA registration for WAVE files, which is why I thought audio/x-wav would be more appropriate. WDYT? An additional column mentioning the format might be nice for readers. Sorry, by mentioning the format do you mean a link to the specification that defines the format? -- Marcos Caceres http://datadriven.com.au
Re: File API Feedback
On 6/30/09 1:44 PM, Ian Hickson wrote: On Tue, 30 Jun 2009, Olli Pettay wrote: File API should probably have some way to get only parts of the file. getAsXXX(long long offset, long long length). Then uploading huge files could be split and decoding video (or something like that) in JS might become possible. This is something we need for XHR too https://bugzilla.mozilla.org/show_bug.cgi?id=496533 I'd rather just have an API that lets you split a File into a sequenceFileData (where FileData is what File inherits from) of equally sized chunks, or something like that, than something that lets you get chunks out in particular forms. Yeah, that sounds better. Then XHR .send() could accept FileData as a parameter. All the .getAsXXX methods would move to that interface and there should be something like FileData getFileData(long long offset, long long length) -Olli
Re: [widgets] Rule for finding a file within a widget package
On Wed, Jun 10, 2009 at 5:24 PM, Anne van Kesterenann...@opera.com wrote: On Wed, 10 Jun 2009 17:20:25 +0200, Marcos Caceres marc...@opera.com wrote: On Wed, Jun 10, 2009 at 4:57 PM, Anne van Kesterenann...@opera.com wrote: TO BE WRITTEN, PLEASE IGNORE if normative material is yet to be written you cannot enter Last Call. Per http://www.w3.org/2005/10/Process-20051014/tr.html#return-to-wg it seems you have to publish this as Working Draft again. You are reviewing the (bleeding-edge) editor's draft, Anne. Not the published one. That is obviously not in the published draft [1], it's just something I put in there yesterday during the F2F and have not had a chance to finish yet... I will finish that bit tomorrow. Obviously, that won't be in the final draft. [1] http://www.w3.org/TR/widgets/ Oh ok. All the more reason the cited process document applies though, methinks. Understood and I see what you mean. I will continue editing and then let the chairs and team contacts decide if we need to republish or if we can proceed to CR. Is that OK? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [widgets] Verify Zip archive
On Wed, Jun 10, 2009 at 5:33 PM, Anne van Kesterenann...@opera.com wrote: It would actually be nice if a Zip archive with a single folder was allowed so you could just package a folder as Zip and ship it. Is that deliberately excluded? Yes, this is deliberately excluded in 1.0. Although that would be a nice feature, it was not identified by the WG as a requirement [1]. For the DoC, please indicate if you are satisfied with this response from the WG. [1] http://www.w3.org/TR/widgets-reqs/ -- Marcos Caceres http://datadriven.com.au
RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
Hi Marcin, Hi Cameron,
My name is Steffen Krüssel and I am participating in the BONDI initiative,
especially in the interface specification for camera and geolocation. Regarding
your conversation about the current geolocation IDL, I just want to clarify the
meaning of the [Callback] extended attribute, as for me the description in the
current WebIDL specification is still not clear.
Why do we have to extend the datatype interface PositionOptions (which only
provides input data for a function, e.g., getCurrentPosition()) with
[Callback]? PositionOptions will not be called back by the
getCurrentPosition() implementation, but rather provides complex input data
(i.e. attributes on the given object).
[WebIDL]:If the [Callback] extended attribute appears on an interface, it
indicates that the interface can be implemented by an ECMAScript native object
(see section 4.5 below), and such an object can be passed to a host object
expecting an object that implements the interface.
Must the PositionOptions object be an ECMAScript native object and what are
the cutbacks if it would not? Perhaps you can give a short example on the
impact of not extending the given interface with [Callback]?!
Thank you both in advance
Steffen
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Marcin Hanclik
Sent: Friday, June 26, 2009 10:26 AM
To: Cameron McCormack
Cc: WebApps WG
Subject: RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
Hi Cameron,
Thank for your comments.
It is clear now.
I’ll probably loosen the IDL grammar to allow
sequences of square-bracketed extended attributes instead of requiring
them to be all in one, but for now you do need to have them all in one,
comma separated.
As for me it is not necessary to loosen the IDL grammar.
Listing the extended attributes separately was my problem within the example
and I am sorry for that.
Stability of the spec seems important.
Thanks.
Kind regards,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
-Original Message-
From: Cameron McCormack [mailto:c...@mcc.id.au]
Sent: Friday, June 26, 2009 2:51 AM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
Marcin Hanclik:
Following our conversation on the geolocation ML
http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0173.html
I have the following clarification request related to the Web IDL spec.
In the geolocation spec we have now:
[NoInterfaceObject]
interface PositionOptions {
attribute boolean enableHighAccuracy;
attribute long timeout;
attribute long maximumAge;
};
Proposed and agreed in our mail discussion:
[Callback]
interface PositionOptions {
attribute boolean enableHighAccuracy;
attribute long timeout;
attribute long maximumAge;
};
Our intentions are:
1) Not to instantiate the interface object with new PositionOptions();
This is handled by not specifying [Constructor] extended attribute.
2) Not to have PositionOptions on the ES global object.
This shall be handled by specifying [NoInterfaceObject]. But it
seems to have to be removed.
3) Use PositionOptions interface to specify properties of the object
passed to e.g. getCurrentPosition() method.
This is handled by specifying [Callback].
4) Resulting from the above, use the PositionOptions as follows:
navigator.geolocation.getCurrentPosition(successCallback,
errorCallback,
{maximumAge:60});
Right.
Questions:
a) What is the PropertyOnly argument/identifier for?
It seems unclear from the Web IDL spec.
Does it specify that the interface has one attribute only and ES
binding just one property?
Or does it specify that the interface includes only attributes?
Or does it signify only the opposite to FunctionOnly?
I’ll try to clear up the wording in
http://dev.w3.org/2006/webapi/WebIDL/#native-objects.
The intended meaning of [Callback=PropertyOnly] is that if the interface
has one or more operations with the same name (but no others) and no
attributes, then an ECMAScript Function object’s [[Call]] will not be
considered to be the implementation of those operations. Instead, the
[[Call]] of the object returned from invoking [[Get]] with the operation
identifier as the property name will be.
So for example with these interfaces:
interface Target {
void registerListener(in Listener x);
};
[Callback]
interface Listener {
void f();
};
this would work:
getTarget().registerListener(function() { … })
as would:
getTarget().registerListener({ f: function() { … } });
If [Callback=FunctionOnly] was specified, then only the former would
work (passing a Function object), while if [Callback=PropertyOnly] was
Re: File API Feedback
On Tue, Jun 30, 2009 at 2:25 PM, Olli Pettay wrote: On 6/30/09 1:44 PM, Ian Hickson wrote: I'd rather just have an API that lets you split a File into a sequenceFileData (where FileData is what File inherits from) of equally sized chunks, or something like that, than something that lets you get chunks out in particular forms. Yeah, that sounds better. Then XHR .send() could accept FileData as a parameter. All the .getAsXXX methods would move to that interface and there should be something like FileData getFileData(long long offset, long long length) For the record, Gears' Blob (the almost-equivalent of that FileData if I'm not mistaken) has a slice(offset,length) method: http://code.google.com/apis/gears/api_blob.html (and a Blob can be passed to an HttpRequest's send() method, and obtained from an HttpRequest's responseBlob property or in desktop's openFiles callback; note that a File in Gears doesn't inherit Blob, it rather has a 'blob' property of type Blob) -- Thomas Broyer
Re: File API Feedback
On 6/30/09 4:07 PM, Thomas Broyer wrote: On Tue, Jun 30, 2009 at 2:25 PM, Olli Pettay wrote: On 6/30/09 1:44 PM, Ian Hickson wrote: I'd rather just have an API that lets you split a File into a sequenceFileData(where FileData is what File inherits from) of equally sized chunks, or something like that, than something that lets you get chunks out in particular forms. Yeah, that sounds better. Then XHR .send() could accept FileData as a parameter. All the .getAsXXX methods would move to that interface and there should be something like FileData getFileData(long long offset, long long length) For the record, Gears' Blob (the almost-equivalent of that FileData if I'm not mistaken) has a slice(offset,length) method: http://code.google.com/apis/gears/api_blob.html (and a Blob can be passed to an HttpRequest's send() method, and obtained from an HttpRequest's responseBlob property or in desktop's openFiles callback; note that a File in Gears doesn't inherit Blob, it rather has a 'blob' property of type Blob) But blob doesn't allow one to access the data (which is why I don't like the API). -Olli
Re: A+E todo
On Mon, Jun 29, 2009 at 6:46 PM, Robin Berjonro...@berjon.com wrote: Hi, here's a list I've collected of things that still need to be done to A+E (I did an editorial pass today). It might not be complete, others are more than welcome to add to it: - viewMode needs to refer to Widgets-WM. Can we agree on what we need to FPWD that one so that there's something to point to? - locale doesn't make much sense: it's a DOMString that is set to the value of user agent locales, which is an array. Our current algorithm wouldn't allow us to pick one, so it could either be a string joining all of those (as in HTTP) or a sequenceDOMString. But I'm not at all convinced that this is useful and I recommend dropping it. Yes, I'm pretty sure we already agreed to this during the F2F. - for width and height we should be clearer on what is meant by viewport - preferences needs to be finalised - onmodechange shouldn't be Function, it should be ModeChangeEvent, and ModeChangeEvent should have [Callback=FunctionOnly] - showNotification() needs a better definiion, getAttention() could perhaps be clarified a little I'll work on some of those tomorrow, feedback is welcome in the meantime. -- Robin Berjon - http://berjon.com/ Feel like hiring me? Go to http://robineko.com/ -- Marcos Caceres http://datadriven.com.au
Re: http://dev.w3.org/2006/waf/widgets/#reserved-file-and-folder-names
Hi Kai, On Mon, Jun 22, 2009 at 3:26 PM, Kai Hendryhen...@iki.fi wrote: What happens if people sprinkle icon.pngs for use in their own application? Nothing. A default icon is an reserved icon whose file name case-sensitively and exactly matches a file name given in the file-name column of the default icons table. To be clear, I added the words and exactly to the above in the spec. Or use index.html in other directories? Nothing. Treated as an arbitrary file - this was already implied in the spec. To make this explicitly clear, I've added: If a user agent encounters a file matching a file name given in the file name column of the default start files table in an arbitrary folder, the user agent must treat that file as an arbitrary file. For example, foo/bar/index.html would be treated as an arbitrary file. Or god forbid, put a config.xml not in the top level directory? What do you mean? this is where config.xml are expected? reserve for me implies that Widget developers are forbidden for using the same filenames. i'm probably dead wrong. anyway could be clearer. The spec states: [[ Reserved means that a character, or text string, or file-name, or folder-name has a specified purpose and semantics in this specification or in some other specification or system. The intended purpose for any reservation is given when the term is used. Arbitrary means that a character, or text string, or file-name, or folder-name is not reserved for the purpose of this specification. ]] Is that not clear enough? Can you help me make that more clear? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
2009/6/30 Kruessel, Steffen steffen.krues...@fokus.fraunhofer.de:
Hi Marcin, Hi Cameron,
My name is Steffen Krüssel and I am participating in the BONDI initiative,
especially in the interface specification for camera and geolocation.
Regarding your conversation about the current geolocation IDL, I just want to
clarify the meaning of the [Callback] extended attribute, as for me the
description in the current WebIDL specification is still not clear.
Why do we have to extend the datatype interface PositionOptions (which only
provides input data for a function, e.g., getCurrentPosition()) with
[Callback]? PositionOptions will not be called back by the
getCurrentPosition() implementation, but rather provides complex input data
(i.e. attributes on the given object).
[WebIDL]:If the [Callback] extended attribute appears on an interface, it
indicates that the interface can be implemented by an ECMAScript native
object (see section 4.5 below), and such an object can be passed to a host
object expecting an object that implements the interface.
Must the PositionOptions object be an ECMAScript native object and what are
the cutbacks if it would not? Perhaps you can give a short example on the
impact of not extending the given interface with [Callback]?!
[Callback], despite the names, does not mean that the interface will
be called back by a method accepting it (although that was the initial
use case). It barely means that you can convert an Object (in the
ECMAScript sense) to an object in the WebIDL sense, of that interface.
Without [Callback], passing something to getCurrentPosition() that is
not an host object of the right type causes TypeErrors, following
section 4.1.16. With [Callback] on the PositionOptions interface,
everything is first converted to an object and then to an object
implementing PositionOptions (with undefined attributes, if needed).
Moreover, because your interface is not a single-operation interface
(it has attributes and no operations), it does not matter if you
choose FunctionOnly or PropertyOnly.
This is explained in
http://dev.w3.org/2006/webapi/WebIDL/#native-objects, but I agree
that some clarification (and maybe a better name than [Callback])
would be better.
Thank you both in advance
Steffen
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Marcin Hanclik
Sent: Friday, June 26, 2009 10:26 AM
To: Cameron McCormack
Cc: WebApps WG
Subject: RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
Hi Cameron,
Thank for your comments.
It is clear now.
I’ll probably loosen the IDL grammar to allow
sequences of square-bracketed extended attributes instead of requiring
them to be all in one, but for now you do need to have them all in one,
comma separated.
As for me it is not necessary to loosen the IDL grammar.
Listing the extended attributes separately was my problem within the example
and I am sorry for that.
Stability of the spec seems important.
Thanks.
Kind regards,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
-Original Message-
From: Cameron McCormack [mailto:c...@mcc.id.au]
Sent: Friday, June 26, 2009 2:51 AM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
Marcin Hanclik:
Following our conversation on the geolocation ML
http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0173.html
I have the following clarification request related to the Web IDL spec.
In the geolocation spec we have now:
[NoInterfaceObject]
interface PositionOptions {
attribute boolean enableHighAccuracy;
attribute long timeout;
attribute long maximumAge;
};
Proposed and agreed in our mail discussion:
[Callback]
interface PositionOptions {
attribute boolean enableHighAccuracy;
attribute long timeout;
attribute long maximumAge;
};
Our intentions are:
1) Not to instantiate the interface object with new PositionOptions();
This is handled by not specifying [Constructor] extended attribute.
2) Not to have PositionOptions on the ES global object.
This shall be handled by specifying [NoInterfaceObject]. But it
seems to have to be removed.
3) Use PositionOptions interface to specify properties of the object
passed to e.g. getCurrentPosition() method.
This is handled by specifying [Callback].
4) Resulting from the above, use the PositionOptions as follows:
navigator.geolocation.getCurrentPosition(successCallback,
errorCallback,
{maximumAge:60});
Right.
Questions:
a) What is the PropertyOnly argument/identifier for?
It seems unclear from the Web IDL spec.
Does it specify that the interface has one attribute only and ES
binding
[cors] Comments on 17 March 2009
I have some basic comments and questions on Cross-Origin Resource Sharing, W3C Working Draft 17 March 2009 http://www.w3.org/TR/2009/WD-cors-20090317/ Perhaps some of these have been answered already and there are probably others I did not list. 1. GET can have side effects, so can we assume it is safe? Thus does it not also always require pre-flight check? 2. How is Origin set, is it always correct, how is it set for widgets? Perhaps the document should discuss this. 3. Is there a race condition between preflight request and subsequent request? What if server changes policy, e.g. allowed methods in this time. Is there a requirement on the maximum time between both these actions? 4. Shouldn't the specification require header integrity protection so they cannot be rewritten during transit? This could require TLS or secure channel or header signing so the mechanism may not be defined in the specification, but shouldn't integrity protection be a MUST? 5. Will Access-Control-Allow-Origin header scale if all possible URLs must be listed (I'm thinking of airline example) . 6. Security sections should be normative and have normative statements. Section 3 - remove statement that section is non-normative - Replace Authors of client-side Web applications are strongly encouraged to validate content retrieved from a cross-origin resource as it might be harmful. with Authors of client-side Web applications SHOULD validate content retrieved from a cross-origin resource as it might be harmful. editorial, replace This section lists advice that did not fit anywhere else. with This is general security considerations, more detailed are provided in specific sections. Section 5.3 - remove statement that section is non-normative - Replace “are strongly encouraged to” with SHOULD in paragraph 1 - Replace “are strongly encouraged to” with SHOULD in paragraph 2 - Replace To provide integrity protection of resource sharing policy statements usage of SSL/TLS is encouraged. with statement that Integrity protection for headers MUST be provided. This MAY take the form of TLS, header signing, or other mechanisms, as appropriate. Section 6.3 - remove statement that section is non-normative - Why is the statement User agents are to carefully follow the rules set forth in the preceding sections to prevent introducing new attack vectors. needed? Remove it, since the normative rules in this specification must be followed for compliance, and if important should be normative. - Replace “are allowed to” with SHOULD in paragraph 2 - Replace “are encouraged to” with SHOULD in paragraph 3 - Replace User agents are encouraged to apply security decisions on a generic level and not just to the resource sharing policy. with These MUST apply equally to access through APIs (e.g. XMLHttpRequest) or through inlined content (e.g. iframe, script, img). (taking from WARP) It might be that I do not understand this statement, some clarification would be helpful. - Replace “is encouraged” with MUST in last sentence. 7. Is there a resolution to Mark Nottingham's concerns expressed in http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0226.html ? Aren't these reasonable concerns? 8 Is the party of permissions the site (origin) requesting the content? What about per-identity permissions? How will this work with OAuth etc? Will this be a general issue? 9. What is the resolution to the confused deputy concern? Should the specification note the concern? I'm not sure if the WG has discussed/ resolved this issue. 10 requirements section: Requirement #1 - What is the implied alternative for additional protection than firewall? 11 requirements section: Is Requirement #2 accurate given that GET can have side effects so is not always safe? 12 requirements section: How did Requirement #4 impact this specification? How does this attack come into play with this specification and if it does, how does the specification address it? 13 requirements section: Is requirement #8 possible? Isn't configuration required to return headers, deal with pre-flight requests etc? Or would this be addressed by Mark Nottingham's suggestion to always return access header? 14 requirements section: Requirement #17, does this include integration with identity management solutions? 15 Editorial: Abstract Extend sentence This document defines a mechanism to enable client- side cross-origin requests. to say, by whom. Mention widgets as well as web browser cases in abstract? 16 Editorial: Section 1 The user agent validates that the value and origin of where the request originated match. Value has not been defined. Sentence is not very clear. 17 Editorial: Section 1 Replace User agents are enabled to discover whether a cross-origin resource is prepared to accept requests using a non-GET method from a given origin. with User agents are enabled via
Re: [cors] Additional Comments on 17 March 2009 cors draft
One additional question regarding a cross-site get (using browser here for simplicity of terms) (for example, see [1]) Is it true that 1. the GET results in the content being returned on the wire with a Access-Control-Allow-Origin header 2. the browser then checks this header and enforces policy 3. if policy disallows then the browser does not allow the content to be used. In any case, doesn't this open an attack to get the content by sniffing the wire for the response content, regardless of the header? regards, Frederick Frederick Hirsch Nokia [1] http://arunranga.com/examples/access-control/SimpleXSInvocation.txt On Jun 30, 2009, at 11:11 AM, Hirsch Frederick (Nokia-CIC/Boston) wrote: I have some basic comments and questions on Cross-Origin Resource Sharing, W3C Working Draft 17 March 2009 http://www.w3.org/TR/2009/WD-cors-20090317/ Perhaps some of these have been answered already and there are probably others I did not list. 1. GET can have side effects, so can we assume it is safe? Thus does it not also always require pre-flight check? 2. How is Origin set, is it always correct, how is it set for widgets? Perhaps the document should discuss this. 3. Is there a race condition between preflight request and subsequent request? What if server changes policy, e.g. allowed methods in this time. Is there a requirement on the maximum time between both these actions? 4. Shouldn't the specification require header integrity protection so they cannot be rewritten during transit? This could require TLS or secure channel or header signing so the mechanism may not be defined in the specification, but shouldn't integrity protection be a MUST? 5. Will Access-Control-Allow-Origin header scale if all possible URLs must be listed (I'm thinking of airline example) . 6. Security sections should be normative and have normative statements. Section 3 - remove statement that section is non-normative - Replace Authors of client-side Web applications are strongly encouraged to validate content retrieved from a cross-origin resource as it might be harmful. with Authors of client-side Web applications SHOULD validate content retrieved from a cross-origin resource as it might be harmful. editorial, replace This section lists advice that did not fit anywhere else. with This is general security considerations, more detailed are provided in specific sections. Section 5.3 - remove statement that section is non-normative - Replace “are strongly encouraged to” with SHOULD in paragraph 1 - Replace “are strongly encouraged to” with SHOULD in paragraph 2 - Replace To provide integrity protection of resource sharing policy statements usage of SSL/TLS is encouraged. with statement that Integrity protection for headers MUST be provided. This MAY take the form of TLS, header signing, or other mechanisms, as appropriate. Section 6.3 - remove statement that section is non-normative - Why is the statement User agents are to carefully follow the rules set forth in the preceding sections to prevent introducing new attack vectors. needed? Remove it, since the normative rules in this specification must be followed for compliance, and if important should be normative. - Replace “are allowed to” with SHOULD in paragraph 2 - Replace “are encouraged to” with SHOULD in paragraph 3 - Replace User agents are encouraged to apply security decisions on a generic level and not just to the resource sharing policy. with These MUST apply equally to access through APIs (e.g. XMLHttpRequest) or through inlined content (e.g. iframe, script, img). (taking from WARP) It might be that I do not understand this statement, some clarification would be helpful. - Replace “is encouraged” with MUST in last sentence. 7. Is there a resolution to Mark Nottingham's concerns expressed in http://lists.w3.org/Archives/Public/public-appformats/2008Jan/0226.html ? Aren't these reasonable concerns? 8 Is the party of permissions the site (origin) requesting the content? What about per-identity permissions? How will this work with OAuth etc? Will this be a general issue? 9. What is the resolution to the confused deputy concern? Should the specification note the concern? I'm not sure if the WG has discussed/ resolved this issue. 10 requirements section: Requirement #1 - What is the implied alternative for additional protection than firewall? 11 requirements section: Is Requirement #2 accurate given that GET can have side effects so is not always safe? 12 requirements section: How did Requirement #4 impact this specification? How does this attack come into play with this specification and if it does, how does the specification address it? 13 requirements section: Is requirement #8 possible? Isn't configuration required to return headers, deal with pre-flight requests etc? Or would this be addressed by Mark Nottingham's suggestion to always return access header? 14 requirements section: Requirement #17, does this include integration
RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
Hi Giovanni,
Thank you very much for the explanation. I think I do understand now, but I
also think the description as well as the name may be adjusted to something
more meaningful.
Just one final question. If I define a valuetype of a specified interface,
which is then again used as a parameter in a function, I must also extend the
interface by the [Callback] attribute, don't I?
Example:
typedef sequenceMyInterface MyInterfaceArray;
// Is [Callback] needed here?
[Callback] interface MyInterface {
attribute long id;
};
void myFunction(in MyInterface param);
Thanks
Steffen
-Original Message-
From: Giovanni Campagna [mailto:scampa.giova...@gmail.com]
Sent: Tuesday, June 30, 2009 3:38 PM
To: Kruessel, Steffen
Cc: Marcin Hanclik; Cameron McCormack; WebApps WG
Subject: Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
2009/6/30 Kruessel, Steffen steffen.krues...@fokus.fraunhofer.de:
Hi Marcin, Hi Cameron,
My name is Steffen Krüssel and I am participating in the BONDI initiative,
especially in the interface specification for camera and geolocation.
Regarding your conversation about the current geolocation IDL, I just want to
clarify the meaning of the [Callback] extended attribute, as for me the
description in the current WebIDL specification is still not clear.
Why do we have to extend the datatype interface PositionOptions (which only
provides input data for a function, e.g., getCurrentPosition()) with
[Callback]? PositionOptions will not be called back by the
getCurrentPosition() implementation, but rather provides complex input data
(i.e. attributes on the given object).
[WebIDL]:If the [Callback] extended attribute appears on an interface, it
indicates that the interface can be implemented by an ECMAScript native
object (see section 4.5 below), and such an object can be passed to a host
object expecting an object that implements the interface.
Must the PositionOptions object be an ECMAScript native object and what are
the cutbacks if it would not? Perhaps you can give a short example on the
impact of not extending the given interface with [Callback]?!
[Callback], despite the names, does not mean that the interface will
be called back by a method accepting it (although that was the initial
use case). It barely means that you can convert an Object (in the
ECMAScript sense) to an object in the WebIDL sense, of that interface.
Without [Callback], passing something to getCurrentPosition() that is
not an host object of the right type causes TypeErrors, following
section 4.1.16. With [Callback] on the PositionOptions interface,
everything is first converted to an object and then to an object
implementing PositionOptions (with undefined attributes, if needed).
Moreover, because your interface is not a single-operation interface
(it has attributes and no operations), it does not matter if you
choose FunctionOnly or PropertyOnly.
This is explained in
http://dev.w3.org/2006/webapi/WebIDL/#native-objects, but I agree
that some clarification (and maybe a better name than [Callback])
would be better.
Thank you both in advance
Steffen
-Original Message-
From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On
Behalf Of Marcin Hanclik
Sent: Friday, June 26, 2009 10:26 AM
To: Cameron McCormack
Cc: WebApps WG
Subject: RE: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
Hi Cameron,
Thank for your comments.
It is clear now.
I’ll probably loosen the IDL grammar to allow
sequences of square-bracketed extended attributes instead of requiring
them to be all in one, but for now you do need to have them all in one,
comma separated.
As for me it is not necessary to loosen the IDL grammar.
Listing the extended attributes separately was my problem within the example
and I am sorry for that.
Stability of the spec seems important.
Thanks.
Kind regards,
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
-Original Message-
From: Cameron McCormack [mailto:c...@mcc.id.au]
Sent: Friday, June 26, 2009 2:51 AM
To: Marcin Hanclik
Cc: WebApps WG
Subject: Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
Marcin Hanclik:
Following our conversation on the geolocation ML
http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0173.html
I have the following clarification request related to the Web IDL spec.
In the geolocation spec we have now:
[NoInterfaceObject]
interface PositionOptions {
attribute boolean enableHighAccuracy;
attribute long timeout;
attribute long maximumAge;
};
Proposed and agreed in our mail discussion:
[Callback]
interface PositionOptions {
attribute boolean enableHighAccuracy;
attribute long timeout;
attribute long maximumAge;
};
Our intentions are:
1) Not to instantiate the interface
Re: [WebStorage] Property enumeration and checking presence
Nikunj R. Mehta nikunj.me...@oracle.com, 2009-06-29 11:04 -0700: There is a requirement to obtain the storage mutex prior to performing Storage interface operations on the localStorage DOM attribute. Section 3.4 asks for obtaining the storage mutex during property enumeration, although this term is not used anywhere else in the document. Similarly, it is not clear what is meant by when checking for the presence of a property that is any different from the getItem() method. The terms storage mutex and obtain storage mutex are defined in the HTML5 draft: http://www.w3.org/TR/html5/browsers.html#storage-mutex http://www.w3.org/TR/html5/browsers.html#obtain-the-storage-mutex -- Michael(tm) Smith http://people.w3.org/mike/
Re: [WebStorage] Property enumeration and checking presence
My question was not clear - I was inquiring about the term property enumeration and not storage mutex. Similarly, I also wanted to know the meaning of checking the presence of a property. Thanks, Nikunj http://o-micron.blogspot.com On Jun 30, 2009, at 9:06 AM, Michael(tm) Smith wrote: Nikunj R. Mehta nikunj.me...@oracle.com, 2009-06-29 11:04 -0700: There is a requirement to obtain the storage mutex prior to performing Storage interface operations on the localStorage DOM attribute. Section 3.4 asks for obtaining the storage mutex during property enumeration, although this term is not used anywhere else in the document. Similarly, it is not clear what is meant by when checking for the presence of a property that is any different from the getItem() method. The terms storage mutex and obtain storage mutex are defined in the HTML5 draft: http://www.w3.org/TR/html5/browsers.html#storage-mutex http://www.w3.org/TR/html5/browsers.html#obtain-the-storage-mutex -- Michael(tm) Smith http://people.w3.org/mike/
Re: File API Feedback
It actually does in the latest version. Blob has a getBytes() method. You can also concatenate blobs together using a new object called a BlobBuilder. I'm in the process of updating the docs and will report back when done. - a On Tue, Jun 30, 2009 at 6:12 AM, Olli Pettayolli.pet...@helsinki.fi wrote: On 6/30/09 4:07 PM, Thomas Broyer wrote: On Tue, Jun 30, 2009 at 2:25 PM, Olli Pettay wrote: On 6/30/09 1:44 PM, Ian Hickson wrote: I'd rather just have an API that lets you split a File into a sequenceFileData (where FileData is what File inherits from) of equally sized chunks, or something like that, than something that lets you get chunks out in particular forms. Yeah, that sounds better. Then XHR .send() could accept FileData as a parameter. All the .getAsXXX methods would move to that interface and there should be something like FileData getFileData(long long offset, long long length) For the record, Gears' Blob (the almost-equivalent of that FileData if I'm not mistaken) has a slice(offset,length) method: http://code.google.com/apis/gears/api_blob.html (and a Blob can be passed to an HttpRequest's send() method, and obtained from an HttpRequest's responseBlob property or in desktop's openFiles callback; note that a File in Gears doesn't inherit Blob, it rather has a 'blob' property of type Blob) But blob doesn't allow one to access the data (which is why I don't like the API). -Olli
Re: Web IDL syntax
Cameron McCormack wrote: * Renamed DOMString to string: http://dev.w3.org/2006/webapi/WebIDL/#idl-string I thought there had been at least some mention of this colliding with existing string types in IDLs that are already in use? I know this will make it much harder for Mozilla to use webidl IDL fragments as is... -Boris
Re: File API Feedback
Ok, it's live now. You can check out the Blob.getBytes() method here: http://code.google.com/apis/gears/api_blob.html And the new BlobBuilder object here: http://code.google.com/apis/gears/api_blobbuilder.html - a On Tue, Jun 30, 2009 at 10:33 AM, Aaron Boodmana...@google.com wrote: It actually does in the latest version. Blob has a getBytes() method. You can also concatenate blobs together using a new object called a BlobBuilder. I'm in the process of updating the docs and will report back when done. - a On Tue, Jun 30, 2009 at 6:12 AM, Olli Pettayolli.pet...@helsinki.fi wrote: On 6/30/09 4:07 PM, Thomas Broyer wrote: On Tue, Jun 30, 2009 at 2:25 PM, Olli Pettay wrote: On 6/30/09 1:44 PM, Ian Hickson wrote: I'd rather just have an API that lets you split a File into a sequenceFileData (where FileData is what File inherits from) of equally sized chunks, or something like that, than something that lets you get chunks out in particular forms. Yeah, that sounds better. Then XHR .send() could accept FileData as a parameter. All the .getAsXXX methods would move to that interface and there should be something like FileData getFileData(long long offset, long long length) For the record, Gears' Blob (the almost-equivalent of that FileData if I'm not mistaken) has a slice(offset,length) method: http://code.google.com/apis/gears/api_blob.html (and a Blob can be passed to an HttpRequest's send() method, and obtained from an HttpRequest's responseBlob property or in desktop's openFiles callback; note that a File in Gears doesn't inherit Blob, it rather has a 'blob' property of type Blob) But blob doesn't allow one to access the data (which is why I don't like the API). -Olli
Re: [WebStorage] Property enumeration and checking presence
On Jun 30, 2009, at 10:28 AM, Michael(tm) Smith wrote: Nikunj R. Mehta nikunj.me...@oracle.com, 2009-06-30 09:12 -0700: My question was not clear Sorry, after re-reading it, I can see now that it was actually pretty clear -- I just misunderstood. I was inquiring about the term property enumeration and not storage mutex. I think in this case it means iterating over the Storage object to get a list of all its properties. Similarly, I also wanted to know the meaning of checking the presence of a property. I think in Javascript terms at least, it means using the in operator to check if the Storage object has a particular property. Is the spec complete in regards to this and does it need to clarify what is meant by these two conditions? I would imagine that these are special ECMAScript cases, am I right?
Re: File API Feedback
Aaron, Thanks for updating the Gears documentation! Ok, it's live now. You can check out the Blob.getBytes() method here: http://code.google.com/apis/gears/api_blob.html There appears to be general support for byte ranged FileData objects. FileData (from which File inherits) will contain asynchronous data accessor functions; this might be an additional method on it, with arguments of offset and length. I'll define it asynchronously. I'll update my draft and report back. And the new BlobBuilder object here: http://code.google.com/apis/gears/api_blobbuilder.html This I'm less sanguine about, since the immediately desired capability is to work with existing system files. -- A*
Re: File API Feedback
On Tue, Jun 30, 2009 at 1:38 AM, Jonas Sickingjo...@sicking.cc wrote: On Mon, Jun 29, 2009 at 11:52 PM, Garrett Smithdhtmlkitc...@gmail.com wrote: Progress-type Events are useful because the API is asynchronous. What if reading the file times out? If an entire directory is uploaded, as in the Picasa-style example, when does the success callback fire? 1) after all files in stress are successfully read 2) upon completion of each file When reading one large file (a movie, for example), how will the program provide notification of progress of the upload? I think you might be misunderstanding the proposed API. The API simply allows reading files from the local file system (once the user has elected to grant the page access to a file). The proposed API is *not* for sending files to a server, for example in a Picasa-style app. The picasa-style example mentioned earlier uses the word upload. I've not used Picasa, but it appears to read files off a local network. It is expected that XMLHttpRequest Level 2 will provide that functionality. Since XMLHttpRequest will be used, you'll have access to the full range of features available in XMLHttpRequest Level 2, such as ability to monitor progress, error and success. OK. What does that have to do with reading a file off the local network? So, the scope of the current File API draft is limited simply reading files from the local file system. With that in mind, do you still think it makes sense to have progress events and all the other events you are proposing? I've reread my message. The arguments and reasoning given for Events seem clear and concise. The argument for Progress Events was illustrated with an example and a comparison. What was confusing? Garrett
Re: File API Feedback
On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smithdhtmlkitc...@gmail.com wrote: With that in mind, do you still think it makes sense to have progress events and all the other events you are proposing? I've reread my message. The arguments and reasoning given for Events seem clear and concise. The argument for Progress Events was illustrated with an example and a comparison. What was confusing? What is the use case for the API you are proposing? I agree that what you are proposing allows for a lot of flexibility, but it also results in an API that is more complex. Thus I think we should stick with the current API unless you have use cases in mind that only works in the API you are proposing. / Jonas
Re: Web IDL syntax
Boris Zbarsky: Are we going to rewrite the existing DOM spec idl to the new syntax as needed (e.g getElementsByTagNameNS)? I do think somebody needs to do that. I don’t think it’s sufficient (even before this syntax change) to just rely on interepreting the OMG IDL published in DOM Core as Web IDL. At the least, [PrototypeRoot] needs to be specified on the Node interface, so that ECMAScript prototype chains for, say, HTMLAElement are set up appropriately. I know that Simon Pieters is working on Web DOM Core http://simon.html5.org/specs/web-dom-core but I am not sure when that will be done. It also won’t include everything from DOM 3 Core. I think it might be useful for someone to just publish versions of existing DOM specs’ IDL as Web IDL. I’m willing to help with that. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] Bugs in DOMString conversion to Unichode characters (was Re: send data using the Web Socket and UCS-2)
Hi David. L. David Baron: This algorithm seems incorrect in two ways: * It gets the ranges for high and low surrogates backwards. (High surrogates are U+D800 - U+DBFF, low surrogates are U+DC00 - U+DFFF, and in UTF-16 a surrogate pair is a high surrogate followed by a low surrogate. So swapping the ranges in the headings should make the algorithm correct, modulo the next point. But you should definitely double-check this. :-) Ouch, you’re right. * It incorrectly handles unpaired high surrogates by eating the next character. Instead, I would prefer that the unpaired high surrogate is replaced by U+FFFD, and the following character is interpreted normally. (That's what Gecko does, anyway. Furthermore, I think it makes sense to match the handling of unpaired low surrogates.) I meant to do that initially, dunno what went wrong. Should be fixed now. http://dev.w3.org/2006/webapi/WebIDL/#dfn-obtain-unicode Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] Callback, PropertyOnly, NoInterfaceObject
Hi Steffen, Giovanni. Giovanni Campagna: [Callback], despite the names, does not mean that the interface will be called back by a method accepting it (although that was the initial use case). It barely means that you can convert an Object (in the ECMAScript sense) to an object in the WebIDL sense, of that interface. I agree with everything Giovanni said. Regarding the name of the extended attribute: it used to be called [NativeObject], but there were restrictions on it so that it could only be used on interfaces with operations (and not attributes). Ian then requested it be renamed to [Callback], since that was more descriptive. Since that restriction has now been lifted, and [Callback] interfaces can have attributes, I agree that [Callback] isn’t the most obvious name any more. Anybody object to renaming it back to [NativeObject] then (or can suggest a better name)? Thanks, Cameron -- Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] Bugs in DOMString conversion to Unichode characters (was Re: send data using the Web Socket and UCS-2)
On Wednesday 2009-07-01 13:02 +1000, Cameron McCormack wrote: I meant to do that initially, dunno what went wrong. Should be fixed now. http://dev.w3.org/2006/webapi/WebIDL/#dfn-obtain-unicode Looks good to me. -David -- L. David Baron http://dbaron.org/ Mozilla Corporation http://www.mozilla.com/
Re: Web IDL syntax
On Jun 30, 2009, at 7:05 PM, Cameron McCormack wrote: Maciej Stachowiak: WebKit doesn't have the same technical constraints as Mozilla, however this change doesn't really seem helpful and it would be annoying to have to replace all instances of DOMString in our existing IDL. find . -name \*.idl | xargs perl -i -pe s/\DOMString\/string/g But OK. By the way, do you use DOMString as an intrinsic type, or do you use a sequenceunsigned long boxed valuetype (as defined in DOM Core)? We treat it as an intrinsic type. I can easily rename the type back to DOMString. I’d like to know if you all think there is any problem in keeping the name as DOMString but removing the null from its set of values, and requiring the use of the nullable type ‘DOMString?’ to specify a string type that does allow null. Because then it is different from the traditional DOMString as defined in DOM Core. I haven't investigated this deeply. I'm not sure it is meaningful in ECMAScript to say that null is not allowed in some particular case - rather, it is necessary to specify what happens when null is passed. There's extended attributes to specify that it should be treated as , undefined, or null, so it seems odd to have a different type to say it should be treated as the string null. I'm not sure if I correctly interpreted what you meant by allow null. Also, as I understand it, there's no way in the Java type system to exclude null from the range of a reference type, so there too it's necessary to say what happens with a null string (exception, same as empty, special behavior different from any string). Regards, Maciej
Re: [WebIDL] grammar in ABNF
Marcin Hanclik: I had the following problem: [45]ScopedName - :: ScopedNameAfterColon | identifier ScopedNameParts Where I assumed that each ScopedName has to start with ::, because according to ABNF this production has to be written as [45ABNF]ScopedName = (:: ScopedNameAfterColon) | (identifier ScopedNameParts) Was the confusion because the ‘:: ScopedNameAfterColon’ and ‘identifier ScopedNameParts’ weren’t written on the same line? I’m not sure that r1.189 is incorrect. It was more complicated, though, since I was trying to make references to DOMString as a non-intrinsic type still work. I am ok with the grammar now. OK great. Anyway, I would put some reference to the syntax of the LL(1). Maybe Aho+Sethi+Ullman's book could be listed there? Yes I might add a reference to that. That’s where I got the ‘→’ and ‘ε’ syntax from, I think. -- Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] grammar in ABNF
Marcin Hanclik: I had the following problem: [45]ScopedName - :: ScopedNameAfterColon | identifier ScopedNameParts Where I assumed that each ScopedName has to start with ::, because according to ABNF this production has to be written as [45ABNF]ScopedName = (:: ScopedNameAfterColon) | (identifier ScopedNameParts) Cameron McCormack: Was the confusion because the ‘:: ScopedNameAfterColon’ and ‘identifier ScopedNameParts’ weren’t written on the same line? Ah I see the confusion is more about how strongly the ‘|’ operator binds compared to adjacent symbols. -- Cameron McCormack ≝ http://mcc.id.au/
