Re: XHR and sandboxed iframes (was: Re: XHR without user credentials)
On Wed, 17 Jun 2009, Mark S. Miller wrote: I don't really understand what we're trying to prevent here. Confused deputies such as XSRF problems. Original paper is at http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html. It's well worth rereading. Much deeper than it at first appears. Could you describe a concrete attack that you are concerned about? I don't really see how the article you cite applies here. Perhaps my own srl.cs.jhu.edu/pubs/SRL2003-02.pdf may help. The threads and links already cited should make the connection with browser security clear. Maybe I'm just too stupid for this job, but I don't understand the connection at a concrete level. I mean, I think understand the kind of threats we're talking about, but as far as I can tell, CORS takes care of them all. I'm not really sure what more to explain. Perhaps you could ask a more specific question? Could you show some sample code maybe that shows the specific threat you are concerned about? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[widgets] RE: PC Last Call comments 1..7+
Hi Marcos, All, I have reviewed the answers and I am satisfied with all the responses to my PC Last Call comments as listed below. Thanks. Kind regards, Marcin [widgets] PC Last Call comments, 1 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0658.html [widgets] PC Last Call comments, 2 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0660.html [widgets] PC Last Call comments, 3 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0656.html [widgets] PC Last Call comments, 4 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0659.html [widgets] PC Last Call comments, 5 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0662.html [widgets] PC Last Call comments, 6 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0705.html [widgets] PC Last Call comments, 7 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0715.html [widgets] PC Last Call comments, interoperability http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0657.html [widgets] PC Last Call comments, versioning http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0655.html [widgets] PC Last Call comments, viewmodes, referencing other specs, guarantee of consistency http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0729.html [widgets] PC Last Call comments, zip-rel-path ABNF http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0661.html 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] RE: PC Last Call comments 1..7+
Awesome! Thanks for all your help, Marcin! Your comments were really helpful and improved the spec significantly. Kind regards, Marcos On Thursday, June 18, 2009, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Marcos, All, I have reviewed the answers and I am satisfied with all the responses to my PC Last Call comments as listed below. Thanks. Kind regards, Marcin [widgets] PC Last Call comments, 1 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0658.html [widgets] PC Last Call comments, 2 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0660.html [widgets] PC Last Call comments, 3 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0656.html [widgets] PC Last Call comments, 4 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0659.html [widgets] PC Last Call comments, 5 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0662.html [widgets] PC Last Call comments, 6 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0705.html [widgets] PC Last Call comments, 7 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0715.html [widgets] PC Last Call comments, interoperability http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0657.html [widgets] PC Last Call comments, versioning http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0655.html [widgets] PC Last Call comments, viewmodes, referencing other specs, guarantee of consistency http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0729.html [widgets] PC Last Call comments, zip-rel-path ABNF http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0661.html 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 http://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. -- Marcos Caceres http://datadriven.com.au
RE: [widgets] RE: PC Last Call comments 1..7+
Hi Marcos, Thanks for all the fixes, reviews of the reviews and all your hard work! Enjoy your holidays! 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: marcosscace...@gmail.com [mailto:marcosscace...@gmail.com] On Behalf Of Marcos Caceres Sent: Thursday, June 18, 2009 2:55 PM To: Marcin Hanclik Cc: public-webapps Subject: Re: [widgets] RE: PC Last Call comments 1..7+ Awesome! Thanks for all your help, Marcin! Your comments were really helpful and improved the spec significantly. Kind regards, Marcos On Thursday, June 18, 2009, Marcin Hanclik marcin.hanc...@access-company.com wrote: Hi Marcos, All, I have reviewed the answers and I am satisfied with all the responses to my PC Last Call comments as listed below. Thanks. Kind regards, Marcin [widgets] PC Last Call comments, 1 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0658.html [widgets] PC Last Call comments, 2 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0660.html [widgets] PC Last Call comments, 3 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0656.html [widgets] PC Last Call comments, 4 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0659.html [widgets] PC Last Call comments, 5 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0662.html [widgets] PC Last Call comments, 6 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0705.html [widgets] PC Last Call comments, 7 http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0715.html [widgets] PC Last Call comments, interoperability http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0657.html [widgets] PC Last Call comments, versioning http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0655.html [widgets] PC Last Call comments, viewmodes, referencing other specs, guarantee of consistency http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0729.html [widgets] PC Last Call comments, zip-rel-path ABNF http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0661.html 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 http://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. -- Marcos Caceres http://datadriven.com.au 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.
widgets feedback
http://dev.w3.org/2006/waf/widgets/
Date: Tue, Jun 16, 2009 at 2:52 AM
2:29 AM me: hey
suppose that times square becomes widget capable
2:30 AM and starts running widgets, like a Clock.wdgt
who's the end user? :){
9 minutes
2:40 AM me: Bluetooth is spelled as such, no capital T
(i.e., users can share widgets over non-HTTP distribution channels,
such as BlueTooth, a USB thumb drive, etc.).
the idea of using both 'i.e.' and 'etc.' in the same parenthetical
scares me. although it might be correct in this instance
2:41 AM Supported means that a user agent implements a said specification,
said - mentioned ?
a said sounds really odd
2:42 AM maybe listed, indicated, ... dunno
Initialization means a run through the steps for processing a widget
package post installation of a widget.
post = after ?
2:43 AM As well as sections marked as non-normative, authoring
guidelines, diagrams, examples, and notes in this specification are
non-normative.
is hard to parse.
As well as sections marked as non-normative, authoring
guidelines, diagrams, examples, and notes in this specification are
non-normative.
2:44 AM In addition to (non-normative marked|marked non-normative)
sections, all authoring guidelines, ... and notes in this
specification are ... non-normative.
2:46 AM There are four classes of products that can claim conformance
to this specification:
2:47 AM that = which ?
(very uncertain about that)
2:49 AM Other legacy/proprietary widget types can be supported by a
user agent, but a user agent must conform to this specification when
dealing with a widget package.
should this say:
2:52 AM While a conforming user agent may support other
legacy/proprietary widget types in order to conform to this
specification it must treat widget packages as according to this
specification.
widgets feedback
Date: Tue, Jun 16, 2009 at 11:42 AM 8:42 AM me: A conformance checker (CC) is a user agent that verifies if a widget package and a configuration document conform to this specification. if = whether 56 minutes 9:38 AM me: liwhen the a class=no-toc no-num href=#rule-for-verifying-a-file-entry0rule for Verifying a File Entry/aspan/span is applied to the file, it returns the empty span is probably a bug 9:39 AM 6.3 Reserved File and Folder Names Reserved File Names you need to change 'xml' to '.xml' and similar 9:40 AM The [Widgets-DigSig] specification also defines the naming conventions for a distributor signature and the naming convention for an author signature. i think you want 'for distributor signatures' and 'for author signatures' (plural for both) 19 minutes 10:00 AM me: via a an access control policy. drop a 10:02 AM Marcos: end user should not be defined, me thinks me: fine by me 10:03 AM Marcos: I'm too nice to people like Benoit who want things like that defined but are not actually useful in the spec 10:06 AM Re: said - mentioned? I like said as it implies that a thing will be mentioned when the term is used. However, if you think it causes confusion, I will change it or clarify it 10:07 AM used mentioned 10:09 AM me: given? a said just sounds really odd a google search for a said fails the hits are all for people :) 10:14 AM Marcos: all fixed now :) 10:15 AM fixed for both supported and unsupported. No other instances found. 10:19 AM me: so, i'm not a fan of out of scope of (very few google hits), i prefer beyond the scope of (millions of hits) 10:20 AM Marcos: nice 10:21 AM me: The start file of a widget package is a file that is used by the user agent when the widget is instantiated. kinda useless statement you use the configuration file when the widget is instantiated too 10:22 AM you kinda want to somehow explain that it's more than a file that's used. although w/o limiting things to DOM style :) 10:25 AM does Default Start File actually specify the order in which one is found and if so, does it define a name for the thing that's found? When a start file is not explicitly declared via the content element, then start file will be one of the default start files. 10:26 AM it'd be better if you could just reference the algorithmically determined start file instead of hand waving at a list 31 minutes 10:58 AM me: might not be supported on all user agents. on = by then Make sure that the widget is labeled with an why is Make capitalized? Marcos: no reason 11:00 AM me: you use case-sensitively 5 times and as case-sensitive 4 times i don't like the latter :) as case-sensitive = case-sensitively 11:01 AM Marcos: sorry, distracted with our big product launch http://unite.opera.com/ 11:02 AM me: yeah, sorry, i don't care ;-), but i don't need realtime responses :) 17 minutes 11:19 AM me: feature name=http://example.com/camera; param name=autofocus value=true/ random blank line between those two? width = 200 viewmodes = application fullscreen 11:20 AM most things line up in this tag's attribute list, except viewmodes preference name =apikey 11:21 AM this tag doesn't get spaces after =,... if you're trying to demo lots of different styles, ok, but please note that somewhere, otherwise, ick :) Be sure to declare the widget namespace as part of the widget element. If the namespace is absent, then Zip archive will be treated as an invalid Zip archive. 11:22 AM it's odd to mark a zip file as invalid because of an error in the widget shouldn't the widget be invalid instead ? 11:24 AM Some general rule rules (plural) 11:28 AM Keyword list attribute oh fun, this,is,forbidden 11:30 AM do we need to say that ., .., ..., are interesting? 11:33 AM either by default as part of the [XML] specification (as is the case with xml:lang) or if the user agent implements the optional [ITS] specification. i don't think either .. if is a well accepted concept :) 11:34 AM drop either (it only fits either .. or) 5 minutes 11:40 AM me: Avoid subtags from the IANA Language Subtag Registry marked as deprecated, grandfathered, or redundant. The intended purpose of the xml:lang attribute is to declare the primary language of an element, its attributes, and its descendent nodes. shouldn't CC's complain about them too? 11:42 AM A valid URI that denotes an identifier for the widget. It is optional for authors to use this attribute. why mention 'authors'? does anyone else write this file? :)
[widgets] Draft Minutes from 18 June 2009 Voice Conference
The draft minutes from the June 18 Widgets voice conference are available at the following and copied below: http://www.w3.org/2009/06/18-wam-minutes.html WG Members - if you have any comments, corrections, etc., please send them to the public-webapps mail list before 25 June 2009 (the next Widgets voice conference); otherwise these minutes will be considered Approved. -Regards, Art Barstow [1]W3C [1] http://www.w3.org/ - DRAFT - Widgets Voice Conf 18 Jun 2009 [2]Agenda [2] http://lists.w3.org/Archives/Public/public-webapps/ 2009AprJun/1028.html See also: [3]IRC log [3] http://www.w3.org/2009/06/18-wam-irc Attendees Present Art, Josh, Marcin, AndyB, Benoit, Mike, David, Robin Regrets Marcos, Thomas, Frederick, AndySledd Chair Art Scribe Art Contents * [4]Topics 1. [5]Review and tweak agenda 2. [6]Announcements 3. [7]Comments from Dom Hazael-Massieux (12 June and 15 June) 4. [8]Comments from Francois Daoust (14 June) 5. [9]Comments from Opera (15 June; submitted by Marcos) 6. [10]Comments from Dom Hazael-Massieux (17 June) 7. [11]P+C LCWD feedback by Josh Soref 8. [12]Who should review the WARP spec? 9. [13]Who should review the Widget URI Scheme spec? 10. [14]AOB * [15]Summary of Action Items _ trackbot, associate this channel with #webapps trackbot Associating this channel with #webapps... scribe ScribeNick: ArtB scribe Scribe: Art Date: 18 June 2009 abraun me/ nope I was Review and tweak agenda AB: I submitted the draft agenda on June 17 ([16]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1 028.html). Any change requests? [16] http://lists.w3.org/Archives/Public/public-webapps/ 2009AprJun/1028.html). Announcements AB: On June 12 the W3C legal staff announced a Public call for prior art on Widgets 1.0 Updates spec ([17]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0 937.html). Please read this announcement and respond accordingly. ... also, today, the First Public Working Drafts of both Widgets Access Requests Policy and Widgets URI Scheme will be published. [17] http://lists.w3.org/Archives/Public/public-webapps/ 2009AprJun/0937.html). timeless_mbp So, I need to send off a final set of comments AB: last announcement from me is reminder June 19 is the deadline for comments for the PC LCWD ... any other announcements? [ None ] scribe ACTION: Barstow send reminder re Widgets Updates Call for Prior Art to public-webapps [recorded in [18]http://www.w3.org/2009/06/18-wam-minutes.html#action01] trackbot Created ACTION-368 - Send reminder re Widgets Updates Call for Prior Art to public-webapps [on Arthur Barstow - due 2009-06-25]. abraun me is using chrome for today IRC session MS: I need to move the FPWD to the right place today ... and then get the Web Master to create the appropriate link AB: what is the ETA, Mike? MS: I can make the move during this call ... and then ping Web Master to make the link AB: great; I appreciate that MS: the DigSig CR annoncement must get done today and OK'ed by PLH; should be no issues AB: thanks for doing that Mike! Comments from Dom Hazael-Massieux (12 June and 15 June) AB: on June 12, Dom submitted comments ( [19]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09 36.html ). We won't cover discuss his Editorial comment on June 15 ( [20]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09 71.html ) since MC already fixed it. ... MC has not responded to this set of comments. Any feedback? ... ideally, responses to Dom should be sent to the mail list [19] http://lists.w3.org/Archives/Public/public-webapps/ 2009AprJun/0936.html [20] http://lists.w3.org/Archives/Public/public-webapps/ 2009AprJun/0971.html Marcin: I reported the same probs against the ABNF ... and I think they are now fixed AB: ok; good ... they appear to be non-substantive i.e. bugs that need to be fixed ... any other feedback on Dom's June 12 comments? [ None ] Comments from Francois Daoust (14 June) AB: On June 14, Francois submitted some new comments ( [21]http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/09 62.html ). There are three comments. Marcos has not responded to this set of comments. Any feedback? ... comment #2 identifies a bug that needs to be fixed before publishing a Candidate spec. ... comment #3 appears to be a suggestion for an optimization we should consider ... any comments or feedback re Francois' comments? [21]
Request for Comments: FPWD of Widgets 1.0: URI Scheme spec
To: public-webapps@w3.org BCC: www-...@w3.org, public-pkg-uri-sch...@w3.org Reply-to: public-webapps@w3.org On June 18, the Web Applications WG published a First Public Working Draft of the Widgets 1.0: URI Scheme spec: [[ http://www.w3.org/TR/2009/WD-widgets-uri-20090618/ Abstract Many specifications in the Web stack depend on a context being defined that includes a current URI. This is easily provided for documents retrieved over HTTP, or from the local file system, but is currently undefined for documents extracted from within a widget package. Such a limitation has a number of implications which this document intends to address. Introduction This specification defines the widget URI scheme for use inside widgets or other such applications of web technology that do not run on the web. ]] If you have any comments, please send them to public-weba...@w3.org. -Regards, Art Barstow P.S. BCC was used for TAG and PKG-URI mail lists to reduce cross-posting
Request for Comments: FPWD of Widgets 1.0: Access Requests Policy spec
To: public-webapps@w3.org BCC: public-device-a...@w3.org Reply-to: public-webapps@w3.org On June 18, the Web Applications WG published a First Public Working Draft of the Widgets 1.0: Access Requests Policy (WARP) spec: [[ http://www.w3.org/TR/2009/WD-widgets-access-20090618/ Abstract This specification defines the security model controlling network access from within a widget, as well as a method for widget authors to request that the user agent grant access to certain network resources (or sets thereof). Introduction User agents running widgets are expected to provide access to potentially sensitive APIs (phone book, calendar, file system, etc.) that expose data which should not be leaked to arbitrary network locations without the user's consent. The purpose of this specification is precisely to define the security model for network interactions from within a widget that has access to sensitive information, and to provide means for a widget to declare the need to access specific network resources so that a policy may control it. ]] If you have any comments, please send them to public-weba...@w3.org. -Regards, Art Barstow P.S. BCC was used for device-apis mail list to reduce cross-posting
widgets feedback
Date: Thu, Jun 18, 2009 at 4:52 PM
4:15 PM me: (e.g., floating and application mode)
either floating mode and application mode
or the floating and application modes
The following example shows the usage of the name element.
widget xmlns=http://www.w3.org/ns/widgets;
name short=Weather
The Ultimate Weather Widget
probably indent The one more space :)
19 minutes
4:35 PM me: file identification table
has 3 columns, one is entirely empty
4:36 PM Step 1 - Acquire a Potential Zip Archive
Step 1 involves acquiring a potential Zip archive
-- Potential v. potential?
4:37 PM A user agent will acquire a potential Zip archive from a data
transfer protocol that either labels resources with a media type (e.g.
[HTTP]) or from a data transfer protocol that does not label resources
with a media type (e.g., BitTorrent, Bluetooth, etc.).
A tautology ...
(yes, i know we're trying to say this, but is there a better way to write it?)
4:39 PM Step 2 - Verify the Zip archive
The previous step used more uppercase letters :)
4:41 PM must treat the value as null(i.e., not as empty string and not
as the text string null).
add a space between 'null' and '('
4:42 PM Configuration Defaults
this table uses column headers and footers, the other ones don't. (just noting)
4:43 PM must attempt to locate digital signatures for the widget (step ).
step number missing
4:44 PM So, for example, fr,en-us,en,en-au,en,fr,en would become
fr,en-us,en-au.
there should be an example of a tripple (zh-hans-cn)
7 minutes
4:52 PM me: ignore means that a user agent must act as if the element,
or fileis not present.
add a space between 'file' and 'is'
widgets spec
btw, don't forget the little people when you make the credits :) have a good vacation, sorry about the delays. all done :)
widgets feedback
Date: Thu, Jun 18, 2009 at 6:48 PM 6:36 PM me: (e.g., a user agent could use an array, or an object, or a hash map, etc.). drop each or 6:41 PM For each element in the elements list, if the element is one of the following: A preference element: doesn't mention readonly (this might be ok, or maybe not...) 6:48 PM 1. For each file name in the default start files table (from top to bottom) that has a media type that is supported by the user agent: 1. Let potential-start-file be the result of applying the rule for finding a file within a widget package to file name. 2. If potential-start-file is null or in error, ignore this file name and move onto the next file name in the default start files table. 3. If potential-start-file is a file, then: 1. Let widget start file be the value of potential-start-file. 2. Let start file content-type be the media type given in the media type column of the default start files table. 3. Terminate this algorithm and go to Step 9. I'm worried about the case where a package has two files: index.svg and index.xhtml. index.svg is 0 bytes and index.xhtml is a well formed xhtml file. The author developed this package using a user agent which doesn't support image/svg+xml and things worked well. A user unfortunately gets the widget and uses it with a user agent which does support image/svg+xml. I'm fairly certain what happens is that this process sends the user agent to step 9 with index.svg and the user ends up unhappy.
Re: Progress Events normative text
On Wed, Jun 17, 2009 at 5:49 AM, Anne van Kesterenann...@opera.com wrote: On Mon, 15 Jun 2009 17:00:46 +0200, Charles McCathieNevile cha...@opera.com wrote: On Sat, 13 Jun 2009 13:54:10 +0200, Anne van Kesteren ann...@opera.com wrote: That definitely makes sense, though please take into consideration that for cross-origin loads exposing the file size cannot be done until all HTTP headers have been received and the requested resource has opted in with CORS. OK. One of the things I intended to keep leaving to the host spec was definining what the size actually refers to. I'd think we would like this to consistently refer to the entity body for all usage of progress events as to not confuse people using the API. It seems odd to take great care in order and naming but not in consistent implementation of the event objects. At the very least we can define that for HTTP request, headers are not used. For things like WebSocket and FutureAwesomeMegaAlienProtocol it might make sense to do something different, perhaps. / Jonas
File API Feedback
It's really great that this is finally moving forward! Here are some preliminary comments on the current draft: http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml I would prefer it if fileName and fileSize were simply named name and size instead. It should be clear from the object what they mean. I think it would be better if the FileError object was not modeled after the DOMException interface. Making it consistent with how SQL errors are handled in Web Storage seems better for consistency. fileName is encoded as a DOMString and is therefore not in UTF-8 but 16-bit code units. Omitting the encoding information would suffice I think. getAsDataURI() is better named getAsDataURL() for consistency with e.g. CSS url(), canvas toDataURL(), and input type=url. (Maybe just getText() and getDataURL()?) Comments on getAsText(): * I assume it is meant that if the encoding parameter is not provided UTF-8 is used for decoding the file. I think that should be made more clear. * However, wouldn't it be better to use e.g. XML rules for XML files and HTML rules for HTML files? * It would also make sense to observe any BOM the file might have and maybe information provided by the platform? Rules similar to how responseText for XMLHttpRequest is computed could be used here I think. * It should also define how to deal with bytes it cannot decode with the given encoding. E.g. replace them with U+FFFD as done elsewhere in the Platform. I think FileDialog is a bad idea. We already have UI for selecting multiple files: input type=file multiple. (And soon with DataTransfer.files we have a second one.) I would much rather wait with FileDialog until it is very clear that we need it. It seems to me that input type=file multiple, the ability to expose files to ECMAScript, and the ability to upload files asynchronously using XMLHttpRequest is pretty much what applications are asking for. The motivation for this feature seems therefore to be purely about UI, which we should try to solve with CSS. There is no need to have duplicate functionality here. -- Anne van Kesteren http://annevankesteren.nl/
Re: File API - W3C Working Draft 7 June 2009
Timeless,
These are all sensible nits and I'll incorporate them.
-- A*
timeless wrote:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml
Note, I expect all of my comments here to be of an editorial nature.
In the Abstract:
use of appropriate [DOM]DOM methods should return a FileList object,
[DOM]DOM has no markup and seems very out of place.
have the ability to manipulate as wide as possible a range of user input,
this is awkward (yes, I should suggest a fix, sorry, not today).
programmatic ways to prompt file selection
prompt _for_ ?
This interface exposes the list of files that has been selected.
_have_ been
When no file has been selected, the length attribute is zero.
If no files are selected,
---
interface FileList {
readonly attribute unsigned long length;
---
You have two spaces before 'length', i'm not quite sure why,
File.fileSize doesn't get this treatment :)
Index into the collection. Valid values are from 0 to length-1
do you want a period here?
and never need to hold more than a few of its bytes in memory
... need never hold ...
Therefore the content of the file may change or cease to be available between
the moment the file is selected and the moment it is accessed.
While I understand that you're trying to explain this, this isn't a
good way to do so, and doesn't clearly explain the problems about
which you're trying to warn.
implementations SHOULD asynchronously use
a FileError object parameter with an errorCode when invoking
the FileErrorCallback callback .
Does this mean that FileAsText will be called before FileErrorCallback?
// I can haz xhr.send(fileAsDataURI);
I believe future generations would appreciate standard English.
Personally, I'd appreciate more consistent indentation/styling wrt. space
Asynchronously provides access to the File object's data as string.
as _a_ string
Additionally, an optional error callback can be provided by the caller, to
determine
whether there is a FileError, and handle it.
This is confusing. Determine doesn't really fit. And personally, I'd
rather a single function with two arguments. I'm always going to be
called, often with null, you might as well just give me an error
object at the same time (and feel free to be lazy about populating
it).
See accept
.
Please arrange for the period to be on the same line as the rest :)
callback of type FileListDataCallback
I don't understand what happens if the caller asks for multiple and
the user only provides one.
This callback handles the files picked by the user, and is called with a
FileList
parameter. If the multiple parameter is used with the open method, this
callback is
invoked with a FileList with a length greater than 1.
The sample you've defined shows an instant problem, total lack of file
identity. In order to do anything useful, someone would have to retain
file state independently, which is likely to be painful.
The accept attribute may be specified to provide user agents
with a hint of what file types the server will be able to accept.
As this is for a Client side API, it'd be best to avoid mention of
server and instead favor web application.
If this optional parameter is used to invoke the open method,
it must consist of a set of comma-separated tokens,
each of which must be an ASCII case-insensitive match for one of the following:
So I can't specify */*? :)
IF the
user interaction layer raised by implementations
has been dismissed without granting permission.
Is the capital F really necessary? :)
Methods in this specification may throw an error, which are reported
an error is singular, are is not.
The file that is trying to be read does not exist.
files are inanimate objects, they don't try to do anything :)
This may be due to it having been moved or deleted after a pointer to it was
please request pointer with reference :)
acquired (e.g. concurrent modification with another application).
This error code has been previously defined in DOMException [DOMCORE].
The file cannot be read. This may be due to permission problems that occur
after a File object has been obtained (e.g. concurrent lock with another
application).
you used acquired earlier, I like obtained better, please be consistent.
Re: File API, Editor's Draft II
Robin, - The indentation of your WebIDL snippets is a bit broken, which makes them hard to read. I've got this nit numerous times; I'm going to fix it. - Do we want to keep FileList? I think we're all tired of those. I know that the sequenceT section of WebIDL hasn't been written, but this could be a good way of encouraging Cameron :) I'd personally be all for killing that interface and just using sequenceFile. I discussed this on #whatwg. Definitely, the sequenceT syntax is much more elegant, but it isn't ready yet. I think FileList's existence primarily as an [IndexGetter] for File doesn't hurt too much. - FileAsText is poorly named IMHO, I had to reparse the description of getAsDataURI several times before I realised that it used FileAsText (which on quick read was immediately classified as for getAsText). How about just FileContent? Agreed. - It might be useful if the FileAsText (or FileContent) callback got a second argument telling it what kind of data it's getting (in this case text or dataUri). No strong feelings on this, just a thought I'm putting out there. I actually want to rework this based on other feedback obtained in IRC (about having FileData as separate from File). I'll circulate that for review. - There's some lexicographic confusion around URI/URL (for a change). Data URLs are called, well Data URLs (as per RFC 2397) and it's also the terminology you use in the prose. Yet the method is called getAsDataURI. Consistency wouldn't hurt, I don't really care which way. Agreed. - Suggestion: how about having a mediaType attribute on File? The system usually knows such things (I believe) and it could be useful for scripts to decide what to do based on what users have picked, or to correctly label the file when interacting with a service (e.g. DAV). Hmm.. the proposal which I received via IRC was to split what is now File into FileData (everything *but* name) and File (name), with File inheriting from FileData. Perhaps mediaType could go with File. - Flash doesn't ask permission to show the file picker, but it requires genuine interaction (as of F10 you can't trigger it without interacting with Flash content). Yes. I've made permission solicitation a MAY pending further discussion with UAs. - For FileListDataCallback what happens if the user cancels? Do I get an error? A defined but empty FileList? I have a slight preference for the latter, but either way the author should be notified. I should make this clearer, but currently if the user cancels, the FileErrorCallback will be called with FileError (with errorCode SECURITY_ERR). Subsequent suggestions from Anne to NOT match what DOMException does might mean cleaning up my error codes and adding some new ones. - General note on asynchronous calls: instead of void, should they return an opaque token which can be used to cancel the request (or provide one way or another of doing that, possibly just having cancel() on the object)? That's available on setTimeout/setInterval, and on XHR — it's generally useful. Having cancel() on *what objects* exactly? Also, WindowTimer may not be the best example. - How do you propose to handle encoding errors? Say a file is UTF8 and I request it as ASCII? Drop what can't be converted? Use a replacement character? Throw an error? In my opinion, charset conversion shouldn't throw any errors, but should try to honor the call as best as possible. I'll make this clearer. All of these are good nits -- thank you! -- A*
Re: widgets spec
On Thu, Jun 18, 2009 at 5:56 PM, timelesstimel...@gmail.com wrote: btw, don't forget the little people when you make the credits :) have a good vacation, sorry about the delays. all done :) Ah, yes. I haven't kept that section up to date - apologies. I'll make sure I update the acknowledgments before we republish. -- Marcos Caceres http://datadriven.com.au
Re: File API Feedback
Anne van Kesteren wrote: I would prefer it if fileName and fileSize were simply named name and size instead. It should be clear from the object what they mean. OK. I think it would be better if the FileError object was not modeled after the DOMException interface. Making it consistent with how SQL errors are handled in Web Storage seems better for consistency. OK. fileName is encoded as a DOMString and is therefore not in UTF-8 but 16-bit code units. Omitting the encoding information would suffice I think. OK getAsDataURI() is better named getAsDataURL() for consistency with e.g. CSS url(), canvas toDataURL(), and input type=url. (Maybe just getText() and getDataURL()?) OK Comments on getAsText(): * I assume it is meant that if the encoding parameter is not provided UTF-8 is used for decoding the file. I think that should be made more clear. Yes -- and it should be made clearer. * However, wouldn't it be better to use e.g. XML rules for XML files and HTML rules for HTML files? This is a good suggestion. * It would also make sense to observe any BOM the file might have and maybe information provided by the platform? Rules similar to how responseText for XMLHttpRequest is computed could be used here I think. OK * It should also define how to deal with bytes it cannot decode with the given encoding. E.g. replace them with U+FFFD as done elsewhere in the Platform. OK I think FileDialog is a bad idea. We already have UI for selecting multiple files: input type=file multiple. (And soon with DataTransfer.files we have a second one.) I would much rather wait with FileDialog until it is very clear that we need it. It seems to me that input type=file multiple, the ability to expose files to ECMAScript, and the ability to upload files asynchronously using XMLHttpRequest is pretty much what applications are asking for. The motivation for this feature seems therefore to be purely about UI, which we should try to solve with CSS. There is no need to have duplicate functionality here. Today, well-known web applications leverage Flash for uploading content, since what browsers do by default when prompted by input type=file... isn't desirable to these applications (with few exceptions). I want The Platform to have an alternative. I *also* agree that CSS + working on input type=file multiple ... are good approaches, but don't agree that we should block on solving the problem that way. I absolutely agree that security issues are critical. I'm interested in hearing from others about this, but I envision some *normative* statements about errors, and some non-normative statements for UAs (along the lines of what I've posted already). Also, I hope to have another version of the specification (cleaned up with everyone's nits that I acknowledge) for circulation next week by Wednesday. -- A*
Re: File API Feedback
On Thu, 18 Jun 2009, Arun Ranganathan wrote: I think FileDialog is a bad idea. We already have UI for selecting multiple files: input type=file multiple. (And soon with DataTransfer.files we have a second one.) I would much rather wait with FileDialog until it is very clear that we need it. It seems to me that input type=file multiple, the ability to expose files to ECMAScript, and the ability to upload files asynchronously using XMLHttpRequest is pretty much what applications are asking for. The motivation for this feature seems therefore to be purely about UI, which we should try to solve with CSS. There is no need to have duplicate functionality here. Today, well-known web applications leverage Flash for uploading content, since what browsers do by default when prompted by input type=file... isn't desirable to these applications (with few exceptions). I spoke with the developers of one of these Well-Known Web Applications, and they didn't even _mention_ the styling difficulties of input type=file as one of the reasons for using Flash here. The feature requests were: - multiselection of photos - file upload progress - dnd of files - local display of images prior to uploading them - filtering by file type (image vs video vs office docs etc) - selecting or uploading a whole folder at once - resuming uploads after browser crash After I prompted them, they said styling of input type=file would be ok too, at least in the way that other form controls are stylable. Therefore I'd rather we didn't include FileDialog yet. As far as I can tell the features above are handled by File, FileList, and simple additions to HTML5: - multiselection of photos -- we have input type=file multiple already - file upload progress -- adding File support to XHR2 addresses this - dnd of files -- adding a .files attribute to DataTransfer addresses this - local display of images prior to uploading them -- see below - filtering by file type (image vs video vs office docs etc) -- we have input type=file accept= already - selecting or uploading a whole folder at once -- input type=file multiple can support many files from a folder - resuming uploads after browser crash -- adding File support to Database or LocalStorage would address this Local display of images before uploading them requires being able to take a File object and poke it into parts of the platform that currently only take URLs. I suggest that the way we address this is by adding an API to a File object that returns a URL like this: scheme:uuid ...where scheme is some new scheme, and uuid is some unique number. Each URL in this scheme would have an intrinsic origin that is equal to the origin of the script context (the first script in HTML5 terms) that invoked the API to get the URL. This URL could then be passed around as a string and would be treated as a resource from the same origin as that script, and could thus be used with img and canvas and so on. This would just need a File.getAsURL() method that mints the URL and returns it. The URLs would have some defined lifetime (e.g. same as the Document, or same as the session, or same as the browser, or something). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: File API Feedback
Ian Hickson wrote: On Thu, 18 Jun 2009, Arun Ranganathan wrote: I think FileDialog is a bad idea. We already have UI for selecting multiple files: input type=file multiple. (And soon with DataTransfer.files we have a second one.) I would much rather wait with FileDialog until it is very clear that we need it. It seems to me that input type=file multiple, the ability to expose files to ECMAScript, and the ability to upload files asynchronously using XMLHttpRequest is pretty much what applications are asking for. The motivation for this feature seems therefore to be purely about UI, which we should try to solve with CSS. There is no need to have duplicate functionality here. Today, well-known web applications leverage Flash for uploading content, since what browsers do by default when prompted by input type=file... isn't desirable to these applications (with few exceptions). I spoke with the developers of one of these Well-Known Web Applications, and they didn't even _mention_ the styling difficulties of input type=file as one of the reasons for using Flash here. This feedback is extremely useful. I, too, would like the chance to speak with the developers of (that particular application) as well as with other developers. Also: Local display of images before uploading them requires being able to take a File object and poke it into parts of the platform that currently only take URLs. I suggest that the way we address this is by adding an API to a File object that returns a URL like this: scheme:uuid ...where scheme is some new scheme, and uuid is some unique number. Each URL in this scheme would have an intrinsic origin that is equal to the origin of the script context (the first script in HTML5 terms) that invoked the API to get the URL. This URL could then be passed around as a string and would be treated as a resource from the same origin as that script, and could thus be used with img and canvas and so on. This would just need a File.getAsURL() method that mints the URL and returns it. The URLs would have some defined lifetime (e.g. same as the Document, or same as the session, or same as the browser, or something). This was mentioned in IRC as well, and I broadly like the idea. I don't mind spec'ing it out as well, but it does add a layer of complexity to what we've already got. This isn't a use case for FileDialog and has nothing to do with input type=file either, however, and I'm keen to hear from others as well about FileDialog vs. solving this with better input type=file support. Also, your discussions with that particular application vendor may have revealed a subset of requirements pertinent to them. We *do* hear that styling is a major issue in feedback we've gathered so far, so I'm not ready to let the point go. To be consistent with the FileData + File approach, getAsURL() might be something on FileData (and not File). -- A*
July 2008 f2f meeting minutes now publicly accessible
Almost one year ago now, we had a face-to-face meeting in Redmond that focused primarily on the CORS spec. Due to simple sloth and neglectfulness, we had left the permissions on the minutes such that they were member-only. But they are now publicly accessible: http://www.w3.org/2008/07/01-wam-minutes.html http://www.w3.org/2008/07/02-wam-minutes.html http://www.w3.org/2008/07/03-wam-minutes.html -- Michael(tm) Smith http://people.w3.org/mike/
W3C and APIs writeup from TAG members
For those on this list who are not also on the www-tag list, this is just a heads-up that there's an informal draft document -- titled W3C and APIS -- that's likely to be of some potential interest to people following the WebApps WG work. It was written by Ashok Malhotra, Larry Masinter, and (I think) Jonathan Rees, and the current version of it is here: http://lists.w3.org/Archives/Public/www-tag/2009Jun/att-0085/W3C_and_APIs.htm -- Michael(tm) Smith http://people.w3.org/mike/
Re: W3C and APIs writeup from TAG members
Michael(tm) Smith wrote: For those on this list who are not also on the www-tag list, this is just a heads-up that there's an informal draft document -- titled W3C and APIS -- that's likely to be of some potential interest to people following the WebApps WG work. It was written by Ashok Malhotra, Larry Masinter, and (I think) Jonathan Rees, and the current version of it is here: http://lists.w3.org/Archives/Public/www-tag/2009Jun/att-0085/W3C_and_APIs.htm This document has a lot of There may be ... in it. It isn't prescriptive about anything yet, and seems to be an exercise in goals drafting. If one of the long term goals is modification of AWWW[1], then that might be worth following. -- A* [1] http://www.w3.org/TR/webarch/
Re: File API Feedback
Ian Hickson wrote: Local display of images before uploading them requires being able to take a File object and poke it into parts of the platform that currently only take URLs. I suggest that the way we address this is by adding an API to a File object that returns a URL like this: scheme:uuid Can't one already get data out of a File object? And if so, is there a reason to not just have a way of getting a data: url representing that data out of one? -Boris
Re: File API Feedback
Boris Zbarsky wrote: Ian Hickson wrote: Local display of images before uploading them requires being able to take a File object and poke it into parts of the platform that currently only take URLs. I suggest that the way we address this is by adding an API to a File object that returns a URL like this: scheme:uuid Can't one already get data out of a File object? And if so, is there a reason to not just have a way of getting a data: url representing that data out of one? This can be done in existing versions of Firefox synchronously, and in the existing editor's draft asynchronously (via getAsDataURI which should be renamed). I think the original discussion about this (re-reading IRC notes) was to have a short-lived URL (as locator, not as a Base64 dump) in the scope of the script that actually referred to the file. Upon reflection, Data URLs satisfy the use case for URLs to ... poke into parts of the platform that currently take only URLs. 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? -- A*
Re: [WebIDL] overloading and fallback
Cameron McCormack: I added [AllowAny] to support this: http://dev.w3.org/2006/webapi/WebIDL/#AllowAny Anne van Kesteren: So a.f(1.23); throws in the example because the method is overloaded? I.e. it would not throw if the method did not accept an A object as argument? Yes. If an operation is not overloaded, then you don’t get TypeErrors thrown because you pass arguments of incorrect types; they are all converted to the appropriate type by the “converting an IDL value to an ECMAScript value” definitions in #es-type-mapping. If an operation is overloaded, then the overload resolution algorithm is more strict about the types of values passed as argument. (See the “If R contains more than one entry:” step of the algorithm.) If so, I suppose that works great, thanks! It seems I didn’t actually modify the overload resolution algorithm to take [AllowAny] into account. I’ve done it now: http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm -- Cameron McCormack ≝ http://mcc.id.au/
Re: [WebIDL] On overloaded operations in an effective overload set
Shiki Okasaka: I see. So the expected ECMAScript behaviour is to try to invoke an operation that can be executed without applying ToString(), ToNumber(), etc., to [AllowAny] parameters firstly, and then look for an invokable operation taking [AllowAny] into account if no such method was found? Sort of. Primitive types are all lumped together, and a ToNumber(), ToBoolean() or whatever will still be applied to the value passed in. I just committed the change to the overload resolution algorithm, which I forgot the other day: http://dev.w3.org/2006/webapi/WebIDL/#dfn-overload-resolution-algorithm It’s clearer now from that algorithm (hopefully) that for a given ECMAScript type/value, certain IDL types are considered appropriate: ECMAScript value Appropriate IDL types --- - Undefined, Boolean, Primitive types, boxed primitive types, any Number String DOMString, any null Object types, boxed valuetypes, DOMString, any Host object Object, any interface type for an interface that the host object implements (or one of its sub- interfaces), any Native objectObject, any interface type for an interface annotated with [Callback], any For a given argument, if there is an overloaded operation that has an appropriate type, all entries in the set of possible operation invocations that have an inappropriate type will be removed. However, if there is no operation that has an appropriate type, but there is one with an inappropriate type but which is annotated with [AllowAny], then it will remain in the set. When it comes to actually invoke the selected operation, the conversions in #es-types that do ToObject() or ToUint32() or whatever will still be performed as appropriate. -- Cameron McCormack ≝ http://mcc.id.au/
Re: File API Feedback
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. It sounds like part of the goal is to be able to retain references to files across crashes. As an example, I occasionally decide to upload the contents of stress (about 1000 images and 100mb iirc). The url for stress can be found in a bug report. 1. User visits uploader page 2. User selects the contents of an entire folder (stress) with a file picker 3. Browser provides relatively tiny urls which are opaque to the Web App for each of the files 4. Web App stores the opaque urls into localstorage 5. Web App asks for the data for the first couple urls 6. Web App starts showing previews and uploading files 7. As files are uploaded, webapp removes opaque urls from localstorage 8. Web app repeats 5-7 w/ other files from 4 9. Browser crashes; web app has uploaded say 100 items of my 1000 items 10. Browser restarts; web app is able to use localstorage and opaque urls to continue uploading the remaining 900 items. the requirements for such an opaque url are: a. that the browser retain a mapping to the real file paths b. that opaque urls the browser hasn't generated for a given web application not be usable by that web application one potential scheme: browser-file-reference://host.principle.example.com:port/opaque-sequence-number note that at this time, the web apps working group is trying to propose a widget: scheme, and the amount of push back web apps is getting from various groups is quite high. -- just something to keep in mind.
RE: File API Feedback
On Thursday, June 18, 2009 6:13 PM, Arun Ranganathan wrote: Boris Zbarsky wrote: Ian Hickson wrote: Local display of images before uploading them requires being able to take a File object and poke it into parts of the platform that currently only take URLs. I suggest that the way we address this is by adding an API to a File object that returns a URL like this: scheme:uuid Can't one already get data out of a File object? And if so, is there a reason to not just have a way of getting a data: url representing that data out of one? This can be done in existing versions of Firefox synchronously, and in the existing editor's draft asynchronously (via getAsDataURI which should be renamed). I think the original discussion about this (re-reading IRC notes) was to have a short-lived URL (as locator, not as a Base64 dump) in the scope of the script that actually referred to the file. Upon reflection, Data URLs satisfy the use case for URLs to ... poke into parts of the platform that currently take only URLs. 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? I'd be concerned about the size. If you have a large file then exploding it into base64 just to copy it somewhere else into the platform where it will be decoded into yet another copy doesn't seem optimal. It may be a good v1 solution though. Ade.
Re: File API Feedback
On Fri, 19 Jun 2009, 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. This is exactly the use case I had in mind, yes. data: URLs are fine for testing and prototyping, but as a practical matter, they don't really scale to real-world needs. For example, imagine a user uploading a local video (~1GB) to YouTube, where the page wants to show the video in a video element as (or immediately before) the user is uploading it (e.g. so the user can set the times where ads should show). A data: URL is clearly not an option here, I think. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Web IDL syntax
Hello WG.
I’m thinking about removing some of the extended attributes in Web IDL
and replacing them with non-extension syntax in the language.
Originally, I had a goal of keeping compatibility with OMG IDL, which is
why many features currently require extended attributes. Upon
reflection, I don’t think compatibility with OMG IDL syntax is a useful
goal, especially when it gets in the way of neatly specifying particular
requirements.
So if we are happy to extend the IDL syntax, I think any extended
attribute that is intended to have some effect across all language
bindings should be moved to the syntax proper. Following are my half
baked proposals. I haven’t them through much; comments very much
welcome.
Thanks,
Cameron
Changes to extended attributes
--
[Callable]
Callable objects would be specified using an operation-like syntax.
interface NumberQuadrupler {
callable float compute(in float x);
};
Would mean that in languages where objects can be callable,
NumberQuadruplers would be callable, but wouldn’t have a method called
“compute”. Languages that do not support callable objects would have
the “compute” method.
You would also be able to specify a separate callable:
interface NumberQuadrupler {
callable float (in float x);
};
where for langauges that don’t support callable objects, there wouldn’t
be any method on NumberQuadrupler objects.
[Constructor]
I’d say to keep this as an extended attribute, but make it be
ECMAScript-specific. If factory methods are required across language
bindings, then explicit factory interfaces should be written.
[ExceptionConsts]
This should be dropped, and instead the IDL syntax would allow constants
to be specified on exceptions directly.
module fileio {
exception FileIOException {
const unsigned short FILE_NOT_FOUND = 1;
const unsigned short READ_ERROR = 2;
const unsigned short WRITE_ERROR = 3;
unsigned short code;
};
};
[ImplementedOn]
I’d like to take up Ian’s suggestion
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0362.html
of syntax to specify when objects implementing interface A always
implement interface B.
Instead of having:
[ImplementedOn=Node]
interface EventTarget {
…
};
you would have:
interface EventTarget {
…
};
Node implements EventTarget;
and for the reverse case, where Anne requested an [Implements] extended
attribute
http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0360.html
you would have:
interface XMLHttpRequestUpload {
…
};
XMLHttpRequestUpload implements EventTarget;
Note that using interface inheritance is slightly different from this
“implements” syntax, since the former makes particular requirements of
the prototype chain in ECMAScript and the actual inheritance hierarchy
in Java.
[{Index,Name}{Creator,Deleter,Getter,Setter}]
As with the “callable” keyword, indexing operations would be specified
with operation-like syntax.
interface OrderedMap {
readonly attribute unsigned size;
getter any getByIndex(in unsigned long index);
setter void setByIndex(in unsigned long index, in any value);
deleter void removeByIndex(in unsigned long index);
getter any get(in DOMString name);
creator setter void set(in DOMString name, in any value);
deleter void remove(in DOMString name);
};
As with “callable”, the “getter”, “creator”, “setter” and “deleter”
modifiers on an operation indicate that if the language binding supports
object indexing like this, the methods won’t exist. To have a getter
that exists in ECMAScript while also keeping the method, you’d do:
interface HTMLCollection {
…
Element item(in unsigned long index);
getter Element (in unsigned long index);
…
};
An alternative would be to reverse the omission of methods, so that
“getter” on an operation would always have both the getter. Then if you
wanted to omit the method if getters are supported you could do
something like:
interface DOMStringMap {
omittable getter DOMString get(in DOMString name);
omittable setter void set(in DOMString name, in DOMString value);
…
};
and getters/setters defined with no operation name would be implicitly
omittable.
Not sure which of the above two ways is better, at the moment.
[NoIndexingOperations]
This wouldn’t be needed, since the above changes to specifying getters
and setter would allow you to specify whether the methods get included
or not.
[Null]
This would become an ECMAScript-specific extended attribute.
[Optional]
Optional arguments would be able to be specified using an “optional”
keyword, like so:
interface ColorCreator {
Object createColor(in float v1,
in optional float v2,
in float v3,
in optional flat alpha);
};
“optional” would still mean “this and all following arguments can be
omitted”.
[Prefix]
This was
Re: Web IDL syntax
Cameron McCormack: Other possible syntax changes - And another one: get rid of the requirement to use forward declarations if you want mutually referencing interfaces. -- Cameron McCormack ≝ http://mcc.id.au/
