Re: Lifetime of Blob URL
As a developer who eagerly awaits this API, I'm fine with using File- prefixes for most everything, since many times a file in many APIs is really an abstraction for a stream of data anyway, and I think that most experienced developers can wrap their heads around that. That's my two cent's worth, Mike On Mon, Aug 30, 2010 at 5:25 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 30, 2010 at 5:23 PM, Jian Li jia...@chromium.org wrote: The other alternative is to have both FileReader and BlobReader, while the former one is for reading only File object and the later one is for reading any Blob object. With that, we also have FileReaderSync and BlobReaderSync. That seems like an excessive solution to the you can read blobs with FileReader even though 'blob' isn't in the name problem. / Jonas On Mon, Aug 30, 2010 at 5:17 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 30, 2010 at 5:14 PM, Dmitry Titov dim...@chromium.org wrote: As for wild ideas, it also could be something more generic, lets say DataReader which can take Blobs and Files (and perhaps something else in the future). Like XHR that has overloaded methods for xhr.open(..). It seems possible that web developers may not realize that File is actually a Blob and may be confused by using BlobReader to read File. (Do I need to make a Blob out of my File first?). They may be equally confused by using FileReader to read Blob though. That would address item 1 on my list. But not item 2 through 4. / Jonas On Mon, Aug 30, 2010 at 4:35 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 30, 2010 at 4:22 PM, Darin Fisher da...@chromium.org wrote: On Mon, Aug 30, 2010 at 1:08 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Aug 30, 2010 at 9:59 AM, Arun Ranganathan a...@mozilla.com wrote: In addition, BlobError and BlobException sound better because these names are consistent with current Blob naming scheme in File API. So we're also going to adopt these new names in the WebKit implementation when we rename FileReader to BlobReader per the spec. *sigh. Naming continues to be hard. Not everyone's thrilled with the proliferation of Blob in the API [1] including other major implementors (my co-editor included ;-)) but I changed it mainly due to Darin/Jian/other objections. I suppose you folks are pretty adamant on the Blob* name? I feel pretty strongly that we should name this back to FileReader, for several reasons: 1. Most people that I talk to dislike the name Blob, much less having it spread to things like BlobReader. 2. My understanding is that the writer counterpart is going to be called FileWriter (is this correct?) Yes, that is what we are currently implementing in WebKit. 3. While it's certainly possible to read Blobs with this, it seems to me like the far most common case will be to read a real file, or part of a file (i.e. the result from myfile.slice()). 4. There is one shipping implementation of FileReader It just seems odd to use an interface named FileReader to read blobs, which may not correspond to files. Consider BlobBuilder, which can be used to construct a Blob from a string. I somewhat agree. But it seems equally strange to use BlobReader to read files, and I suspect that it will be vastly more common to read files than blobs-that-aren't-files. Yes, the File interface inherits Blob, so technically when you're reading a file you're also reading a blob, but I doubt that is the mental model most people will have. Like so many other things, there is no perfect solution here. Another idea (possibly a crazy one) would be to eliminate Blob, and just use File for everything. We could rename BlobBuilder to FileBuilder and have it return a File instead of a Blob. Same goes for Blob.slice(). Of course, the File would not necessarily correspond to a real physical file on disk for performance reasons. I've been thinking about this too. I can't say I feel strongly either way. It feels somewhat strange, but I can't come up with any solid technical reasons against it. / Jonas
Re: Transferring File* to WebApps - redux
Hi, Am I correct in thinking that what you find too restrictive is that the FileSystem API only allows programmatic access to a sandboxed portion of the device's filesystem instead of the entire filesystem? Otherwise, I believe that the File APIs as a whole will allow most of the other operations you mention. --mike On Tue, Jun 15, 2010 at 3:24 PM, SULLIVAN, BRYAN L (ATTCINW) bs3...@att.com wrote: Arun, I am not meaning to be unfair, perhaps the message is not coming through clearly enough. There are specific technical requirements that we need these APIs to fulfill, that I indicated to Thomas in another email: 1) access filesystems on the host device 2) traverse directories 3) read files as they exist on the filesystem (not just a local representation in memory, as currently defined in the File API to my understanding), in bytes and lines 4) write files (similar requirement to write directly to the filesystem), in bytes and lines, with overwrite and append options 5) do the above programmatically in Javascript (not dependent just upon user selection of an input element and interaction with a file selector) 6) provide security for this using the policy-framework approach as being defined for DAP APIs Apart from the details of (1-4) above, which will help ensure are addressed in the current File* APIs (no matter where they are finished),I think it's (5-6) where the real differences are. If we need another API in DAP to address them, then ATT will help ensure it gets done separately from the current File* APIs. The question of where you are represented and your ability to participate cuts both ways - the same is true for us. I think if the browser vendors want their products really to be seen as compatible with the Web application space (as compared to just dynamic Web pages), they will support the work in DAP as its there that non-obtrusive and inherently secure models for Web application access to device resources will be defined as APIs. Thanks, Bryan Sullivan | ATT -Original Message- From: Arun Ranganathan [mailto:a...@mozilla.com] Sent: Tuesday, June 15, 2010 2:53 PM To: SULLIVAN, BRYAN L (ATTCINW) Cc: Robin Berjon; public-device-a...@w3.org; Ian Fette; Web Applications Working Group WG Subject: Re: Transferring File* to WebApps - redux On 6/15/10 2:24 PM, SULLIVAN, BRYAN L (ATTCINW) wrote: Arun, The basic concern I have is with the notion of browsers as the only Web context and use-case that matters. The browser-based model for API integration view (as I understand your position) is that the user must be actively involved in every significant action, and choose explicitly the actions that enable integration with browser-external resources (including local and remote). Step back and you will see the inconsistency in that (what would Ajax be if the user had to approved every HTTP API request via aninput element?). In the case of the File API, I'm merely stating that the capability should be an evolution on top of what web pages already do with respect to the input element, and not introduce a new unbounded API space which doesn't consider user involvement, or reconsiders it with other consent models. Equating ajax with this in general isn't relevant to the argument. If you have no substantial technical differences with FileReader, FileWriter, and the FileSystem API, why are you blocking them from moving? What additional oversight does the DAP WG provide, that the WebApps WG does NOT provide? The WebApps WG has MORE browser vendors than the DAP WG, allowing review that's pertinent to the technology we are building. Below, you say: Webapps are much more than just dynamic Web pages. They are applications, and with HTML5 will have the ability to rival desktop applications, as is clearly the vision of many in the industry. It might even enable a return to a thin client world (e.g. browser as OS) in which most significant resources are cloud-based. I see the logic and value in that, but it's not the only valid (and valuable) model. W3C focuses on the Web, and the Web is bigger than the browser use-case. HTML5 and the APIs that attach HTML-based applications to the world can actually be the application platform for the next era of the Web, but only if we do not limit the options to the user-centric/control paradigms of the past. But, by charter, the DAP WG allows you to address those very use cases! If the FileWriter, FileSystem, and FileReader specifications do NOT address the vision you articulate above, why not create a specification relevant to your use case? Naturally, browser vendors see value in technology that serves the cause of dynamic web pages. Why are you disallowing maximum browser vendor review by prohibiting a sensible move? Even within the DAP WG, feedback isn't as forthcoming on these specifications as it is in the WebApps WG. Please reconsider your
