[FileReader API, ProgressEvents] Design patterns, FileWriter API
Hi, This is a set of architectural comments to the FileReader API, ProgressEvents and the design patterns for DAP. For DAP in [1] I propose the following consistency requirement (still [1] is a very early draft with bugs): All APIs MUST follow the same convention when handling callback functions (e.g. XHR / FileReaderAPI style with onreadystatechange, or ProgressEvents with EventTarget). There is currently discrepancy between XHR/FileReaderAPI and the ProgressEvents in terms of handling the same functionality differently. The ProgressEvents specification proposes is the event firing order [2], that could be summarized as a firing grammar (up to some lack of clarity around suspend and stalled events): progressgrammar = loadstart working (error | abort | load) loadend working = *( progress | (progress suspend progress) | (progress stalled progress) ) In my opinion some part of the design from ProgressEvents is taken over in FileReader API too directly. Specifically the event names are the same as within the ProgressEvents, but I assume they should be adjusted to the FileReader API. Therefore instead of (forgetting the above issue with the callback model for now): attribute Function onloadstart; attribute Function onprogress; attribute Function onload; attribute Function onabort; attribute Function onerror; attribute Function onloadend; we could have: attribute Function onreadstart; attribute Function onprogress; attribute Function onread; attribute Function onabort; attribute Function onerror; attribute Function onreadend; Assuming that we will have an interface like FileWriter in the (near) future, we could already now anticipate that the interface would include e.g. the following: attribute Function onwritestart; attribute Function onprogress; attribute Function onwrite; attribute Function onabort; attribute Function onerror; attribute Function onwriteend; Then, the ProgressEvents spec could act as a design pattern definition for lengthy, asynchronous operations. To make it happen, the names of the events there could be changed to be generic: loadstart - start progress stalled suspend error abort load - done loadend - end Additionally the ProgressEvents spec could be divided (or split into two documents? ) to contain the section specific to the design pattern definition and to the section specific to data transfer / loading. What to you think? Thanks, Marcin [1] http://dev.w3.org/cvsweb/~checkout~/2009/dap/design-patterns/Overview.html?rev=1.1content-type=text/html;%20charset=iso-8859-1 [2] http://dev.w3.org/2006/webapi/progress/Progress.html#Event1 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: CORS and HTTP error responses
On Tue, 17 Nov 2009 01:45:53 +0100, Robert O'Callahan rob...@ocallahan.org wrote: This suggests that the client should expect --- and the server should send --- CORS headers such as Access-Control-Allow-Origin:* in HTTP error responses for public resources. Does that make sense? The spec seems to be silent on the issue. That's exactly what should happen, yes. The specification is status code agnostic apart from redirects. Anything I can do that makes that more clear? -- Anne van Kesteren http://annevankesteren.nl/
[widgets] Interface published
Hi all, Widget interface spec ready for publication (Last Call) [1]. Will be out sometime today (if not already published). And test suite files are now online [2]. Enjoy in moderation! Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-api/ [2] http://dev.w3.org/2006/waf/widgets-api/test-suite/
[widgets] Request for Comments: LCWD of Widget Interface; deadline 8 December 2009
Begin forwarded message: From: ext Marcos Caceres marc...@opera.com Date: November 17, 2009 11:50:04 AM EST To: public-webapps public-webapps@w3.org Subject: [widgets] Interface published Archived-At: http://www.w3.org/mid/4b02d43c.2040...@opera.com Hi all, Widget interface spec ready for publication (Last Call) [1]. Will be out sometime today (if not already published). Thanks Marcos! And test suite files are now online [2]. [[ ++ MWTS WG ]] Enjoy in moderation! Kind regards, Marcos [1] http://dev.w3.org/2006/waf/widgets-api/ [2] http://dev.w3.org/2006/waf/widgets-api/test-suite/ Note this spec was formally published as the Widgets APIs and Events spec. If you have any comments re this LCWD: http://www.w3.org/TR/2009/WD-widgets-apis-20091117/ Please send them to public-webapps@w3.org by 8 December at the latest. -Art Barstow
Re: [widgets] Request for Comments: LCWD of Widget Interface; deadline 8 December 2009
Le mardi 17 novembre 2009 à 12:01 -0500, Arthur Barstow a écrit : And test suite files are now online [2]. [[ ++ MWTS WG ]] [2] http://dev.w3.org/2006/waf/widgets-api/test-suite/ To be fair, that work only represents Marcos’s efforts so far — I did contribute some test cases, but they haven’t been integrated or reviewed yet. Definitely Marcos++ :) Dom
[Widgets] LCWD#3 comments (1)
Hi, A couple of comments to the latest PC. 7.4 Media type attribute Media type attribute defines the grammar and refers to RFC2045/6. What about referring to RFC4288 that includes the grammar required for MIME registration [1]? (I have no strong opinion about this point, though.) Numeric attribute For example, the characters 002, 323, 23214 Could be For example, the character strings 002, 323, 23214 7.11.1 When an icon element is used, it is required for authors to use the src attribute. Should be an authoring guideline. 7.13.1 that a user agent will behave as the required attribute Should be that a user agent will behave as if the required attribute Acknowledgments It seems a paragraph is missing there. Thanks, Marcin [1] http://tools.ietf.org/html/rfc4288#section-4.2 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: Proposal for sending multiple files via XMLHttpRequest.send()
On Tue, Nov 10, 2009 at 7:48 AM, Jonas Sicking jo...@sicking.cc wrote: Yay! On Tue, Nov 10, 2009 at 4:06 PM, Anne van Kesteren ann...@opera.com wrote: WebKit presently supports sending File. It does not support FileData yet. Is Content-Type set to anything specific if the author has not set it? // FIXME: Should we set a Content-Type if one is not set. ^^^ looks like it presently depends on the web page setting the C-T header manually :-/ I think that should be fixed to be based on the system's knowledge of the file's mime type. So far I have only added support for Blob (the new FileData) of these two and set the Content-Type to application/octet-stream if not provided by the Web author. Should I also add File and set the Content-Type to File.mediaType? I definitely think so yes. Agreed. Same thing for the send() function. On a separate note, is sending application/octet-stream really better than simply sending no Content-Type header at all when sending a Blob (or a File with empty mediaType)? I think it is probably wise to default to sending a content type that explicitly says i don't know the type on the grounds that being explicit is better than not. -Darin
Re: Proposal for sending multiple files via XMLHttpRequest.send()
On Nov 17, 2009, at 10:32 AM, Darin Fisher wrote: On Tue, Nov 10, 2009 at 7:48 AM, Jonas Sicking jo...@sicking.cc wrote: Yay! On Tue, Nov 10, 2009 at 4:06 PM, Anne van Kesteren ann...@opera.com wrote: WebKit presently supports sending File. It does not support FileData yet. Is Content-Type set to anything specific if the author has not set it? // FIXME: Should we set a Content-Type if one is not set. ^^^ looks like it presently depends on the web page setting the C- T header manually :-/ I think that should be fixed to be based on the system's knowledge of the file's mime type. So far I have only added support for Blob (the new FileData) of these two and set the Content-Type to application/octet-stream if not provided by the Web author. Should I also add File and set the Content-Type to File.mediaType? I definitely think so yes. Agreed. Same thing for the send() function. On a separate note, is sending application/octet-stream really better than simply sending no Content-Type header at all when sending a Blob (or a File with empty mediaType)? I think it is probably wise to default to sending a content type that explicitly says i don't know the type on the grounds that being explicit is better than not. According to HTTP, I think sending no Content-Type more strongly indicates that you don't know the type. In particular, missing content type gives the recipient license to sniff the content. Regards, Maciej
Re: comments from Osmosoft on the File API
Greetings Paul :) At Osmosoft, we took some time to collectively read the File API Editor's Working Draft 28 October 2009: Thank you very much for taking the time, and sending your review comments. My responses below: Overall we welcome the formalization of access to local files, including binary data within a client-side Web application and can envisage migrating a number of features currently implemented using access to a file:// URI TiddlyWiki if and when it becomes available in browser implementations. This is good to know. Do you specifically mean the urn (or url) feature that the specification has solicited feedback about, or anything else? During our review we have one overall disappointment: whilst the Use Cases describe saving local files programatically, the specification does not provide any write methods. We wondered if these were to be provided in a later version or via extensions? --We now gather this is a topic of debate within the WG and with the DAP WG. Write methods are forthcoming in a subsequent version of the File API. My understanding currently is that ongoing work on file writing will follow in the Web Apps WG, and iterate on the current File API. We do have some very minor comments which we hope will help move the specification forward. * Status of this Document The Status section states this is the work of the Web Applications Working Group, but we were unable to find mention of the spec from the Working Group page, or in the list of chartered deliverables: http://www.w3.org/2008/webapps/ http://www.w3.org/2008/webapps/charter/webapps-deliverables.html What is the current expectation of the status of the published document? Is it on the Recommendation track, or will it be published as a Working Group Note? It is *very soon* to be published as a FPWD. What is the relationship between the File API document and the File Upload API listed on the historical Web API WG page? http://www.w3.org/2006/webapi/ http://www.w3.org/TR/file-upload/ The API you have just reviewed deprecates the File Upload API that you cite above. * Acknowledgements Where is the original document from Robin Berjon? A link to the input document may help us better understand the context of this specification. In fact, you have already referenced it, namely: http://www.w3.org/TR/file-upload/ I don't think much is gained by linking to this document directly, since it contains some non-starters, and is likely to confuse developers, since the two drafts differ significantly. A brief history of the File specification is: 1. The initial API proposal had synchronous read methods, which actually had been implemented in Firefox (but which we'll deprecate somehow over the course of time, since Firefox 3.6 introduces support for the File API in my draft). But synchronous reads from the main thread weren't a palatable direction for the web, and Apple in particular raised strong objections. 2. An asynchronous draft followed. But this didn't account for progress events. 3. The current draft introduced asynchronous file access as well as progress events. * Processing Models Much of the specification seems to be written in terms of pseudo-code steps. Whilst this follows the style of parts of the HTML 5 specification, and simplifies cloning a working implementation, it can make it harder to read and more difficult to write tests for than a series of assertions. I'd suggest wherever possible, replacing the processing steps with a set of inputs, observable changes of state and outputs, even if this does make the specification more verbose. Can you give me an example? Do you think introducing more sample code will address this concern? In particular, are there areas of prose that you think are unclear? * Conformance The terminology used for conformance currently links within the document, rather than to HTML 5 specification. I don't know what you mean here. Do you mean the practice of putting internal links in square bracket e.g. [HTML5]? This seems to be common practice, so that all references are cited clearly in the references section. We'd also suggest adopting the HTML 5 colours for terminology, internal and external references. A a frag-id for each individual assertion, along with a table listing all of the assertions at the end of the document useful when building test suites. Do you feel that terminology, and references, are *hard to read* or this an argument for consistency? I've labored to make the specification referenced and hyper-linked, and am reluctant to have a template change without a clearly stated payoff. Can you point me to any specifications that have frag-ids for individual assertions that help building test suites? * Normative references Along with the authors, it would be useful to have an indication of the current status of each of the documents
Re: more flexible ABNF for STS?
=JeffH wrote: In talking with a couple folks in the past few days, it seems that there already is some thinking about adding some additional directives (aka header field value tokens) to the STS header field. One such idea is an EVonly flag with nominal semantics of accept only an EV cert. In general, having a header field (or any protocol element) that is a syntactic moving target is an issue because of the what to do about deployed implementations? will they break? question. I noticed a suggestion (included below at end of this msg) from Hixie wrt BNF techniques to address this sort of situation without employing explicit versioning information in a header field syntax (or any other BNF based syntax) This seems interesting to me, so I hacked up the below sample syntax to see what it looks like. Seems like it might be workable, tho it would add a fair bit to a spec both in terms of syntax specification but also explaining the technique. But, adding explicit versioning is also a pain. Below's a couple of quick examples/experiments with re-coding the STS header field ABNF grammar using Hixie's ideas. thoughts? ... Isn't that simply the standard approach used in many IETF specs with respect to defining an extensibility point (except it's usually prefixed ext, not invalid)? BR, Julian
Re: [FileAPI] File.mediaType
Marcin Hanclik wrote: What if the @type is derived from unverified metadata and the UA relies on the underlying OS (assuming the file is local) ? Does it mean that the UAs should always sniff to ensure that the @type is correct? Should we apply the procedure similar to the one from PC that derives the @type from the file name [4]? [4] http://dev.w3.org/2006/waf/widgets/Overview.html#rule-for-identifying-the-media-type-of-a User agents can use a variety of different steps to determine the type of a file. For instance: https://developer.mozilla.org/En/How_Mozilla_determines_MIME_Types#ExternalHelperAppService I am not sure it is necessary to specify a common approach here, but it is useful to specify what happens when the user agent cannot determine the type. I've made the following changes: 1. I agree that name consistency is desirable, so mediaType is now simply type. I'll point out that style.type expects very few types back, whereas for files, the picture is more complicated, so simply calling it type has drawbacks, but since mediaType isn't used elsewhere on the platform, I agreed that reusing the same name was desirable. mediaType The ASCII-encoded string in lower case representing the media type of the file, expressed as an RFC2046 MIME type [RFC2046]. Although IANA registered types are all lower case, the subtypes are not (not sure whether we want to mandate the toLower() normalization in the FileReader API). Therefore I suggest referring to IANA and RFC4288. 2. I've put in an editor's note to mention IANA and RFC4288. I'm not sure *exactly* how useful subtypes are here, but it's worth making the specification text more robust. What if the @type is derived from unverified metadata and the UA relies on the underlying OS (assuming the file is local) ? Does it mean that the UAs should always sniff to ensure that the @type is correct? I think UAs *should* try to determine that the type is correct, but don't think this is a *must*. 3. The empty string is returned if user agents cannot make a determination. -- A*
Re: [widgets] Request for Comments: LCWD of Widget Interface; deadline 8 December 2009
On Tue, Nov 17, 2009 at 6:14 PM, Dominique Hazael-Massieux d...@w3.org wrote: Le mardi 17 novembre 2009 à 12:01 -0500, Arthur Barstow a écrit : And test suite files are now online [2]. [[ ++ MWTS WG ]] [2] http://dev.w3.org/2006/waf/widgets-api/test-suite/ To be fair, that work only represents Marcos’s efforts so far — I did contribute some test cases, but they haven’t been integrated or reviewed yet. Definitely Marcos++ :) Dom is correct. Apologies, I should have made it clear as to what constitutes the test suite at present: The test suite has 100% coverage of the English prose that contains the word MUST in a normative sense - the tests served as a way for me to proof read the specification. That is, the intent of the current test cases is to double check that prose could be translated into tests that run on an identified product (in this case, a user agent). The tests do not thoroughly test the WebIDL, which Dom's IDL test case generator will thoroughly tests. I will work with Dom on getting those tests into the test suite over the next week or so. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
[FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
Julian Reschke wrote: Arun Ranganathan wrote: The latest revision of the FileAPI editor's draft is available here: http://dev.w3.org/2006/webapi/FileAPI/ ... 4. A suggestion to *not* have a separate scheme (filedata:) in lieu of urn:uuid:uuid[2] has been the basis of a rewrite of that feature in this version of the specification. ... Is there a particular reason why a specific URI scheme needs to be called out at all? (there are other schemes that may be more flexible, for instance because they allow using a UUID/String pair for identification). This is a useful question to answer :) I assume everyone understands use cases for this identifier. Ian's email discusses a few [1] which have been supplemented with a few more. There are a few ways to proceed: 1. We could coin a new scheme such as the originally proposed filedata: scheme. This has the advantages of associating behavior (and semantics) with a scheme, so that existing schemes aren't confused or co-opted inappropriately. However, actually registering a new scheme used by browsers seemed problematic (with overhead due to coordination with multiple groups). I'm willing to revisit this idea given enough feedback, but to date, haven't really received enough of it. 2. We could reuse an existing scheme. This seemed desirable if there was little chance of confusion and collision, and it avoids multi-group coordination. Using urn:uuid was an obvious choice given assumptions on UUID uniqueness, but it is hardly a pave the cowpaths choice since it isn't currently used on the web platform in any way I can recognize. Also, urn isn't used on the web platform as an attribute on interfaces, but url is, so we once again have a consistency argument. While consistency is desirable, I don't think we should be too hung up on it. To make a longer story shorter, urn:uuid addressed the use case fairly well, and seemed a useful starting point. [ Now between 1. and 2., I'd say the deciding factor might be implementation feedback. For instance, Firefox's code is such that 1. and 2. are both (pretty much) *equally* feasible. We also got some feedback from Microsoft [2], but that feedback seems to be preliminary, with more to come. I'm also not sure concern over origin issues are valid here [2], since a perusal of the issues with jar: (which urn:uuid has been compared to) doesn't reveal any cogent origin effrontery. I'd really like *more* implementor feedback on this issue. ] 3. We could not directly call out a URI scheme at all. The benefit of doing this is we can specify *behavior* without actually getting into details about the actual identifier scheme used. But, the chief reason to not take this course of action is that leaving *anything* unspecified on the web platform leads to reverse engineering in ways that we can't envision currently. Developers may rely on quirks within one implementation and incompatibly use them with other implementations. Having to mimic another user agent's behavior has been a common outcome on the web, due to lack of specifications -- *many* examples of this exist on the web throughout its history. One lesson from the browser competition of the past is to avoid leaving things to guesswork. I'd like us to agree on something, and I'd like that agreement to be bolstered with concrete implementor feedback. -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/1110.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0462.html
Re: [FileReader API, ProgressEvents] Design patterns, FileWriter API
Greetings Marcin, Thanks for the thoughtful feedback. My comments below: In my opinion some part of the design from ProgressEvents is taken over in FileReader API too directly. Specifically the event names are the same as within the ProgressEvents, but I assume they should be adjusted to the FileReader API. Therefore instead of (forgetting the above issue with the callback model for now): attribute Function onloadstart; attribute Function onprogress; attribute Function onload; attribute Function onabort; attribute Function onerror; attribute Function onloadend; we could have: attribute Function onreadstart; attribute Function onprogress; attribute Function onread; attribute Function onabort; attribute Function onerror; attribute Function onreadend; What's in a name? [Floral poetry reference elided :-) ]. You are right to point out that there's some inconsistency in the naming convention. This discussion came up with the discussion of readyState [1] state name changes, when READING was considered as a potential readyState, were it not for consistency with the progress events in question (loadstart, load, loadend... ). We elected to stick to LOADING to match the names of existing progress events with 'load' in them. I'll note that 'onload' is very ubiquitous on the web platform, and has been for a while now. These progress events are also used within XHR. This kind of consistency is very desirable for developer convenience, and in my opinion, trumps the perfect name consideration. We've used consistency in naming before in this specification. Here are a few other examples: 1. INTIAL -- EMPTY, for closer name similarity to HTMLMediaElement's network status. 2. mediaType -- type, for closer name similarity with style.type 3. Error conditions like NOT_FOUND_ERR, SECURITY_ERR, and ABORT_ERR are used in DOMException codes and XHR's error codes respectively, including with the same error code. Essentially, the argument here is to reuse what developers are familiar with. *In particular* I'm swayed by the pervasive use of 'onload' on the web. However, I like your next point: Assuming that we will have an interface like FileWriter in the (near) future, we could already now anticipate that the interface would include e.g. the following: attribute Function onwritestart; attribute Function onprogress; attribute Function onwrite; attribute Function onabort; attribute Function onerror; attribute Function onwriteend; To date, you'll note that progress event nomenclature reflects loading or reading operations, since there are very few write metaphors on the web that have affiliated events bound to them. If the design of the FileWriter is similar to the design of the FileReader (which is something we're currently working on), then I think your names make sense. Then, the ProgressEvents spec could act as a design pattern definition for lengthy, asynchronous operations. To make it happen, the names of the events there could be changed to be generic: I think that just as the names 'load*' were chosen for generic data transfer events (either networked or within a document), and are used within documents loaded in the DOM, XHR, and FileReader, we'll need reusable 'write*' events. Without bikeshedding too much, I like your proposal above, but wonder whether we should use the name 'write*' or something else. Since we already have document.write, 'write' is probably the most vetted string to use here :) loadstart - start progress stalled suspend error abort load - done loadend - end Sure. On this question I'm less opinionated. Additionally the ProgressEvents spec could be divided (or split into two documents? ) to contain the section specific to the design pattern definition and to the section specific to data transfer / loading. I like the proposal to have a section specific to data transfer and loading, but am wary of splitting specs. Input and feedback from the author of the ProgressEvents specification would be welcome here. -- A* [1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0691.html
Blob as URN was Re: [FileAPI] Latest Revision of Editor's Draft
Eric,
I recall you saying at TPAC that you wanted to keep the Blob
interface as small as possible, since it seemed likely to get used in
a lot of places. I think that's an excellent goal, but of course,
having said that, I am immediately going to suggest that you add
something to it.
I'm definitely not averse to additions :) Actually, I'm also following
the discussion initiated by Maciej about BinaryData [2] with
public-script-co...@w3.org. Eventually, I believe ECMAScript will
provide a Binary primitive (perhaps ByteArray), and I think Blob should
expose that primitive. This would be a natural extension of what I
envision Blob to be used for. I also envision natural streaming
extensions to this API.
How would you feel about exposing a way to produce a URN from a
Blob, instead of just getting one from a File?
I'm not averse to it. In fact, it was originally in the Blob interface
(which at that time, was dubbed FileData). We moved it to the File
interface since the understanding of use cases at the time was that
all URL consumers expect a full file. [3] You've provided use cases
that show that this isn't the case, and so we should revisit our earlier
understanding. More on your use cases below:
This seems likely to
have wide-ranging uses. Pretty much anywhere you have a blob of data,
you might want to hand it off to the browser, even if it didn't come
from, or wasn't, a single user-supplied file. Here are a few use
cases, but I'm sure more won't be hard to come up with:
* Viewing a single chapter of a book in a frame.
* Slicing one episode out of a DVD and handing it to the video tag, so
that the player controls start and end at the episode boundaries.
* Analogous to the game-asset archive I mentioned at [1], one might
pack a number of small files together to speed download [using only
HTTP compression], then parse them apart on the client. Picture a
Picasa client written in the web browser; it's got to handle maybe
1+ thumbnails, and putting each in a separate file would be
terribly inefficient. Pulling down a tarfile would be a lot quicker.
I can understand why you'd want *partial* data exposed through a URL,
and why your API may force a type on the partial data. Question:
would a fragment identifier scheme [4] address any of these use cases,
or is this completely orthogonal to the use cases you envision? I ask
because you envision a chapter within a frame but I'm not sure what
the frame data structure is.
it
would seem natural to me do to something like this:
interface Blob {
...
DOMString getURN(in DOMString mediaType,
[Optional] in DOMString contentDisposition,
[Optional] in DOMString name);
};
Given that a File that one gets from the user will still tell you its
name and detected mediaType, and can have a constant urn, there seems
to be no conflict in leaving the File interface as-is and adding
something like getURN to Blob. On the off chance that you want to
override the detected mediaType for a file, force a contentDisposition
of attachment, or change the name, you might still use getURN there as
well.
To be clear: you want the File object's URN capabilities to inherit from
Blob, and not be separate, correct? Thus, each Blob has an affiliated
URN, and when a Blob is a File, it uses the Blob's getURN method?
Can you explain what a contentDisposition is a bit better? Can you
write some psuedo-code showing how contentDisposition is used, perhaps
to flesh out the above use cases?
-- A*
[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0424.html\
[2]
http://lists.w3.org/Archives/Public/public-script-coord/2009OctDec/0093.html
[3] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0609.html
[4] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0587.html
Re: [FileAPI] URL, URI, URN | Re: [FileAPI] Latest Revision of Editor's Draft
Arun Ranganathan wrote: Is there a particular reason why a specific URI scheme needs to be called out at all? (there are other schemes that may be more flexible, for instance because they allow using a UUID/String pair for identification). This is a useful question to answer :) I assume everyone understands use cases for this identifier. Ian's email discusses a few [1] which have been supplemented with a few more. There are a few ways to proceed: ... 2. We could reuse an existing scheme. This seemed desirable if there was little chance of confusion and collision, and it avoids multi-group coordination. Using urn:uuid was an obvious choice given assumptions on UUID uniqueness, but it is hardly a pave the cowpaths choice since it isn't currently used on the web platform in any way I can recognize. I don't think that it matters at all whether it's widely used, as long as it's properly specified. That being said it is used in WebDAV (lock token URIs) and Atom (Atom:id). ... 3. We could not directly call out a URI scheme at all. The benefit of doing this is we can specify *behavior* without actually getting into details about the actual identifier scheme used. But, the chief reason to not take this course of action is that leaving *anything* unspecified on the web platform leads to reverse engineering in ways that we can't envision currently. Developers may rely on quirks within one implementation and incompatibly use them with other implementations. Having to mimic another user agent's behavior has been a common outcome on the web, due to lack of specifications -- *many* examples of this exist on the web throughout its history. One lesson from the browser competition of the past is to avoid leaving things to guesswork. I'd like us to agree on something, and I'd like that agreement to be bolstered with concrete implementor feedback. ... Not requiring a specific scheme is not exactly the same thing as leaving it unspecified. If the *only* use of the identifier is within the API, the syntactical form of the identifier really doesn't matter as long as it's understood by the those parts of the platform that need to. Requiring a specific scheme here seems to be a case of *overspecifying*. Best regards, Julian
Let's turn WebDatabase into a WG Note
Hi guys, I've been thinking about the WebDatabase specification [1] and I've come to two conclusions. (1) We are miles away from consensus on this specification, and, hence, we should _not_ consider putting it out for last call. (2) While good work has gone into the IDL/JavaScript Call Level Interface (CLI), we have made no progress on its SQL language specification and are not likely to in the future. Thus we should publish the CLI as a WG Note titled WebSQLDatabase CLI and curtail active work on this specification in the working group. This is Oracle's official position on this matter. It's not that we aren't brilliant engineers, it's just that we've been stuck with a conundrum without a suitable solution: Standardizing on a SQL CLI without specifying the SQL accepted by the CLI will lead to non-interoperable implementations jeopardizing the goal of this working group - to have a consistent technique for managing stored data in user agents. Standardizing on a language with no readily available implementation will delay adoption and place an unreasonable burden on user agent vendors. Standardizing on the SQL accepted by the CLI based on what is implemented in a certain library (SQLite to be precise) will preclude multiple independent implementations, which is unacceptable as a public standard. So my suggestion is that rather than wrapping this conundrum in an enigma, we wrap it in a WG Note until we find ourselves in a new situation and the answer either becomes apparent or irrelevant. I may not be able to follow up on all the replies as I am on vacation later this week. If so, I apologize in advance and will do my best to reply immediately once I return. Thanks, Nikunj Mehta http://o-micron.blogspot.com [1] http://dev.w3.org/html5/webdatabase/
Re: Let's turn WebDatabase into a WG Note
On Nov 17, 2009, at 9:34 PM, Nikunj R. Mehta wrote: Hi guys, I've been thinking about the WebDatabase specification [1] and I've come to two conclusions. (1) We are miles away from consensus on this specification, and, hence, we should _not_ consider putting it out for last call. (2) While good work has gone into the IDL/ JavaScript Call Level Interface (CLI), we have made no progress on its SQL language specification and are not likely to in the future. Thus we should publish the CLI as a WG Note titled WebSQLDatabase CLI and curtail active work on this specification in the working group. This is Oracle's official position on this matter. I disagree. Publishing a WG Note would be appropriate if we had WG consensus to stop work. I don't think we have consensus to do that. I also don't think we have consensus to proceed to the next step (Last Call). The right maturity level to represent this condition would be Working Draft. Regards, Maciej
Re: Let's turn WebDatabase into a WG Note
On Nov 17, 2009, at 10:17 PM, Maciej Stachowiak wrote: On Nov 17, 2009, at 9:34 PM, Nikunj R. Mehta wrote: Hi guys, I've been thinking about the WebDatabase specification [1] and I've come to two conclusions. (1) We are miles away from consensus on this specification, and, hence, we should _not_ consider putting it out for last call. (2) While good work has gone into the IDL/ JavaScript Call Level Interface (CLI), we have made no progress on its SQL language specification and are not likely to in the future. Thus we should publish the CLI as a WG Note titled WebSQLDatabase CLI and curtail active work on this specification in the working group. This is Oracle's official position on this matter. I disagree. I don't understand your reasons. Publishing a WG Note would be appropriate if we had WG consensus to stop work. Understood I don't think we have consensus to do that. This is what I am trying to bring about. See the reasoning in my original email. It would help if you can respond to the three points why I think we have reached the end of the road. I also don't think we have consensus to proceed to the next step (Last Call). The right maturity level to represent this condition would be Working Draft. Nikunj http://o-micron.blogspot.com
Re: CORS and HTTP error responses
On 11/17/2009 02:42 AM, Robert O'Callahan wrote: It might be worth explicitly mentioning that CORS headers can (and sometimes should) be included in error responses, perhaps with an example of when that would make sense. Maybe I'm over-paranoid but it just struck me (and Jeff Walden) as something that server implementers are likely to overlook. A couple data points: Apache's header-addition directive currently isn't applied to 416 responses; a cursory search suggests that quirk (it's hard to call it a bug except with respect to CORS's particular requirements) might not be in Apache's bug database. Mozilla had to alter its HTTP test server specifically to apply its flavor of header directives to 416 responses. The thought never even crossed my mind that 416 responses might want those customized headers when I reviewed the server's byte-range patch. When fail-fast, fail-silently-and-securely is the default mode of thinking (as it should be when implementing any sort of server), it's an easy thing to forget that custom headers should sometimes be applied to error responses. Explicitly noting that some error responses may require CORS headers would have made me more sensitive to that possibility when I was giving advice as to how to write tests using CORS, and it would have made it more likely I'd have seen the potential problem rather than learned it through someone else's debugging efforts. Jeff
Re: Let's turn WebDatabase into a WG Note
On Nov 17, 2009, at 10:26 PM, Nikunj R. Mehta wrote: On Nov 17, 2009, at 10:17 PM, Maciej Stachowiak wrote: On Nov 17, 2009, at 9:34 PM, Nikunj R. Mehta wrote: Hi guys, I've been thinking about the WebDatabase specification [1] and I've come to two conclusions. (1) We are miles away from consensus on this specification, and, hence, we should _not_ consider putting it out for last call. (2) While good work has gone into the IDL/JavaScript Call Level Interface (CLI), we have made no progress on its SQL language specification and are not likely to in the future. Thus we should publish the CLI as a WG Note titled WebSQLDatabase CLI and curtail active work on this specification in the working group. This is Oracle's official position on this matter. I disagree. I don't understand your reasons. I already sated some reasons in the previous thread about 'parking' the spec. I did not want to belabor the point, since it's clear we don't have consensus within the Working Group on the right way to go. Publishing a WG Note would be appropriate if we had WG consensus to stop work. Understood I don't think we have consensus to do that. This is what I am trying to bring about. See the reasoning in my original email. It would help if you can respond to the three points why I think we have reached the end of the road. I think that the three possibilities you listed are: - Not an exhaustive enumeration of the possibilities. (I realize that at this point, to convincingly show that a good SQL dialect spec is possible will require actually doing it; I'm not sure how or when that will happen but I am looking into it.) - Not sufficient reason to stop work, given that we have multiple willing implementors and so far no problems in practice. Furthermore, stopping work would do practical harm: - A WG Note would stop work without producing a test suite, thus harming interoperability. - A WG Note would leave us with no clear process to fix problems found in the spec in the course of implementation. - A WG Note is harder to resurrect in case of new info than a stalled Working Draft; it would require essentially a new FPWD. - It's likely that Web Database implementors will at some point want to add features, and a WG Note does not provide a suitable path for doing that. And on the flip side, keeping the spec at Working Draft maturity will not harm anyone who is not interested in it. In brief, I do not find your arguments persuasive. I think there are reasons to continue working. I don't expect my reasons to be persuasive to everyone; clearly something will have to change for the Working Group to have consensus on the best path forward. Regards, Maciej
Re: Let's turn WebDatabase into a WG Note
On Nov 17, 2009, at 10:58 PM, Maciej Stachowiak wrote: On Nov 17, 2009, at 10:26 PM, Nikunj R. Mehta wrote: On Nov 17, 2009, at 10:17 PM, Maciej Stachowiak wrote: On Nov 17, 2009, at 9:34 PM, Nikunj R. Mehta wrote: Hi guys, I've been thinking about the WebDatabase specification [1] and I've come to two conclusions. (1) We are miles away from consensus on this specification, and, hence, we should _not_ consider putting it out for last call. (2) While good work has gone into the IDL/JavaScript Call Level Interface (CLI), we have made no progress on its SQL language specification and are not likely to in the future. Thus we should publish the CLI as a WG Note titled WebSQLDatabase CLI and curtail active work on this specification in the working group. This is Oracle's official position on this matter. I disagree. I don't understand your reasons. I already sated some reasons in the previous thread about 'parking' the spec. I did not want to belabor the point, since it's clear we don't have consensus within the Working Group on the right way to go. Publishing a WG Note would be appropriate if we had WG consensus to stop work. Understood I don't think we have consensus to do that. This is what I am trying to bring about. See the reasoning in my original email. It would help if you can respond to the three points why I think we have reached the end of the road. I think that the three possibilities you listed are: From your message it is clear that you are not willing to refute any of the points. That is a good start. - Not an exhaustive enumeration of the possibilities. (I realize that at this point, to convincingly show that a good SQL dialect spec is possible will require actually doing it; I'm not sure how or when that will happen but I am looking into it.) You have not provided a logical explanation of why my list is not exhaustive. Can you show what is left out? - Not sufficient reason to stop work, given that we have multiple willing implementors and so far no problems in practice. More than simply a existential implementation proof is necessary to continue work on WebDatabase. I note that there is a difference between an implementable spec and a public standard. Neither your nor anyone else has made a convincing argument about how WebDatabase will lead to a legal public standard, i.e., be capable of supporting multiple independent implementations. I welcome you to prove me wrong. Furthermore, stopping work would do practical harm: I understand that a lot of good work went on in to WebDatabase as well as the implementations thereof. It is another matter that this effort was misguided from the beginning. Consequentially, WebDatabase doesn't stand a practical chance at becoming a standard. Therefore, we do not see any harm caused by stopping work. In fact, I find it harmful to continue efforts in this direction. - A WG Note would stop work without producing a test suite, thus harming interoperability. Interoperability should only matter if you care for multiple _independent_ implementations. You have already acknowledged in prior emails that this is unlikely to happen, ergo lack of a test suite does no harm. - A WG Note would leave us with no clear process to fix problems found in the spec in the course of implementation. The WG Note is dissuading implementors to go forward with this technique. Therefore, there is no need to fix problems. In any case, no one seems interested in solving the real problem - lack of an interoperable SQL. - A WG Note is harder to resurrect in case of new info than a stalled Working Draft; it would require essentially a new FPWD. The rate at which FPWDs are produced in this WG, this seems like a marginal issue. - It's likely that Web Database implementors will at some point want to add features, and a WG Note does not provide a suitable path for doing that. Again, it is not my intention to convey that WebDatabase is _anything_ other than a passing thought. This is the purpose of the WG Note and, hence, this is a non-issue. And on the flip side, keeping the spec at Working Draft maturity will not harm anyone who is not interested in it. I disagree. WebDatabase is causing real harm to everyone who is not interested in it, which at this point is a large number of members of this WG. In brief, I do not find your arguments persuasive. If you are not willing to be persuaded, then that's your choice. I think there are reasons to continue working. However, these reasons are not logical. I don't expect my reasons to be persuasive to everyone; clearly something will have to change for the Working Group to have consensus on the best path forward. I do expect to arrive at consensus because we should not be spending time on making a standard out of something that is inherently not standardizable in finite
