Re: Discussion of Blob URI Scheme for Binary Data Access | IETF

Bjoern,

Firstly, thanks for your response :-)


On 5/12/11 11:55 PM, Bjoern Hoehrmann wrote:
> * Arun Ranganathan wrote:
>> We'd welcome your feedback, including suggestions about embarking upon
>> an IETF standardization track for this protocol.
> Well there are all sorts of problems with your proposal (bulleted lists
> with half a dozen of items do not belong in an Abstract,

This appears to be a subjective stylistic nit (others in the WebApps WG 
actually like the rapid jump to IDLs), but for what it's worth, there's 
always room for improvement, and the Abstract can certainly be tightened.

> you list RFC
> 1738 as normative reference but the document does not seem to be refer-
> enced at all,

RFC1738 is normative for URLs and for "file://", and in the File API 
those were important considerations while we coined a scheme for URLs to 
access binary data, and added more functionality over what the "file://" 
scheme allows for.  Upon reflection, this reference *can* be moved to 
the informative reference section if it makes you feel more comfortable.

> you mention "Data URLs that do not have media-types" which
> cannot exist because there is a default if no media type is given,

Certainly I'm aware of the default!  And Data URLs without a media-type 
production certainly *can* exist as plain text (which is what Firefox 
does today).  But I mention the lack of media-types simply to provide 
guidance on what to do if the Blob's type attribute is the empty 
string.  Since the slice method of a Blob can force an optional 
media-type, implementers/web developers reviewing the File API called 
for guidance about what to do if one was missing.  Data URLs can include 
a media-type or not include a media-type; this section merely provides 
guidance on what to do with Blob objects that don't have a media type.  
Since you raise a nit here, I'll look for language that's even clearer.


>   you
> have a section on "Creating and Revoking a Blob URI" that does not say
> why you would want to "revoke" a "Blob URI",

I can certainly include a note about why a revocation API is useful, but 
it is generally obvious to web developers: if the reference to a file 
within their application is no longer valid, that file reference should 
generate a 404.  In addition the HTML document cleanup steps, there's a 
revocation API that web developers can use.

> this appears to be a W3C
> technical report, but the latest published version seems to be over six
> months old, and the version before that came about a year after the
> previous draft, even though the W3C requires publication every three
> months, the text for 'readAsArrayBuffer' is the same as the text for
> other methods except for easily missed details, and so on and so forth).

I'd be hard-pressed to find W3C WebApps specifications or editor's 
drafts that *totally* conform to this rule.  It is true, however, that 
Working Drafts of the File API could have been published more often.  
Chalk that up to editors having lots of things to do :-)  
Implementations have typically followed the Editor's Draft as opposed to 
the Working Draft, much as with the HTML specification as a "living 
standard."

The biggest difference with readAsArrayBuffer is that it suggests 
multiple ArrayBuffer objects are returned, which could be made more 
precise.  Whether this is through multiple ArrayBuffer returns depending 
on the point at which "result" is accessed, or whether this is an 
incremented "result" is implementation-specific.  The other differences 
are with encodings, which aren't necessary to mention with respect to 
ArrayBuffers.  Thank you for drawing this to my attention -- this could 
improve.
> However, as far as the HTTPbis Working Group goes, I do not see what we
> could offer as feedback. What do you think someone who knows everything
> about HTTP but not much else should comment on? Could you list some of
> the issues where you are unsure you've made the right decision? Things
> you feel are not optimal, not elegant? Why aren't you using one of the
> many existing schemes? I don't mean to be overly critical, it's just
> that you are essentially asking for help with the document, and I don't
> see how this community in particular could help. Some insight into how
> you are thinking about this proposal in relation to HTTP would help.

Point well taken.  Here's what motivates my email:

1. We've introduced a new scheme essentially touted as the "new and 
better" file:// URI, with functionality useful to web applications, such 
as use alongside <img src=...>, use with XMLHttpRequest (which can have 
a response body of Blob), etc.  The file:// URI scheme was done under 
IETF's aegis and advanced as an RFC; what should we do with respect to 
the blob: URI scheme?  From a standardization perspective, is moving 
towards LC with the File API sufficient?  I felt that this listserv 
might have advice on that matter.

2. I'm also soliciting general feedback.  For example, earlier in the 
process, we thought we'd re-use the URN scheme (specifically, something 
like urn:uuid).  But there were a few drawbacks here.  Firstly, the urn: 
scheme was "alien" to web developers who write JavaScript applications, 
etc.   Secondly, not all user agents were reconciled to using UUID.  
Implementations were surfacing that were vendor-prefixed (e.g. moz-file: 
etc.).  Most implementers preferred a new scheme for various reasons.


> Generally speaking, in the IETF you find people who like to solve what
> problems they encounter. Telling people about the problems you've found
> and what pain you are trying to address is likely to generate the most
> useful feedback (or pointers where to get that feedback from). If I were
> to write your mail, I would start out saying "This is the goal, these
> are the problems, these solutions came to mind but didn't meet the mark
> because of problems such and such, so the idea is to have this which
> solves the problems so and so".


Point well taken.

This is the goal:

1. It was desirable to refer to Blobs of data with a URL.  This was 
useful to refer to textures (used with WebGL, for example), or to 
manipulate files on web pages (use an image on the underlying file 
system as the "src" of an image).  APIs that use URLs, such as 
XMLHttpRequest, behave inconsistently when given file:// URLs today.  So 
we wanted a URL scheme that essentially could be used just about 
anywhere an http URL could be used.

2. It was desirable to have well-defined "retrieval semantics" around 
those Blob resources.  What happens with the underlying file has 
shifted?  What happens when that file is not allowed to be accessed, or 
is destroyed?  Moreover, Blob objects can be created on the fly with the 
BlobBuilder API [1].

The Blob URI was the solution we came up with.  It reused a subset of 
HTTP response codes, and addressed use cases 1. and 2.

Problems along the way was an elaborate discussion of why we 
specifically didn't reuse an existing scheme.


> That would enable people to point out things you've missed, criticise
> the design, understand where you are coming from, give them an idea what
> work has been done and what still needs to be done. It would also give
> an idea of whether you feel you are past that, meaning it might be best
> to focus, say, on how the methods are named, or point out performance or
> usability problems in dealing with large or streamed data sets. You may
> also just be looking for, say, whether the design or the details are in
> some way objectionable from a HTTP perspective. How about XMLHttpRequest
> for that matter? Is that relevant? Do you want to know about how this
> new scheme interacts with existing HTTP frameworks?
>
> The point is that from your message, "we" do not have much of a way to
> connect to your thinking about the proposal, so "we" would largely be
> drawing a blank when thinking about what feedback to provide.


I really appreciate the time you've taken, and hope I've made some 
things clearer.

-- A*

Received on Friday, 13 May 2011 19:02:15 UTC