- From: Eric Uhrhane <ericu@google.com>
- Date: Fri, 2 Apr 2010 17:30:32 -0700
- To: Dmitry Titov <dimich@google.com>
- Cc: Anne van Kesteren <annevk@opera.com>, Michael Nordman <michaeln@google.com>, Darin Fisher <darin@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>
Sorry about the slow response, Dmitry. On Wed, Mar 24, 2010 at 11:29 AM, Dmitry Titov <dimich@google.com> wrote: > Those seem to open up so many edge cases... > If we have a File constructor like this, now we have a new category of File > objects that do have names but are not related to actual files on a local > file system, and perhaps have different lifetime expectations. > Ability to specify a name and content disposition also does not fall in > naturally. For example, is what happens when a blob with 'inline' > disposition used in anchor's href or iframe's src? What happens if one > specifies the creation/modification time parameters? What would it mean to > specify a size parameter in content disposition when underlying Blob also > has size property? We could just disallow any parameter that doesn't make sense in this context. > Even one step back, are we sure there is a use case for Blob.urn? If Blobs > are sliced from the files on a local filesystem that user selected via a > File Dialog, what would be a scenario for slice/load? There were requests to > have a single network resource that can be slice/loaded on arrival, but was > the slicing and loading of local files discussed? The most obvious use case > for local files is to be uploaded, perhaps in slices. Here's a previous discussion of some use cases: http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0506.html > On Wed, Mar 24, 2010 at 1:58 AM, Anne van Kesteren <annevk@opera.com> wrote: >> >> On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman <michaeln@google.com> >> wrote: >>> >>> This has been discussed before, not sure what the conclusion was (if any) >>> http://www.mail-archive.com/public-webapps@w3.org/msg06137.html >>> >>> <http://www.mail-archive.com/public-webapps@w3.org/msg06345.html><snip> >>> >>> In order for the URN to be useful, it would have to have a mediaType >>> associated with it, and then there's content-disposition to think >>> about, which then wants a file name as well...boy, that's a lot of >>> baggage. However, since these aren't really inherent properties of >>> the Blob, just of the way you want the browser to view the Blob, 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); >>> }; >>> >>> </snip> >> >> Wouldn't it be better to have a constructor for File. I.e. >> >> File(Blob, name, type, contentdisposition) >> >> or some such. (Maybe some of the attributes on File should be made >> mutable, i.e. name and mime...) >> >> >> Also, didn't we decide to change URN to URL? As far as I can tell that is >> how Gecko is implementing it. >> >> >> -- >> Anne van Kesteren >> http://annevankesteren.nl/ > >
Received on Saturday, 3 April 2010 00:31:23 UTC