- From: Dmitry Titov <dimich@google.com>
- Date: Wed, 24 Mar 2010 11:29:28 -0700
- To: Anne van Kesteren <annevk@opera.com>
- Cc: Michael Nordman <michaeln@google.com>, Darin Fisher <darin@chromium.org>, Web Applications Working Group WG <public-webapps@w3.org>
- Message-ID: <l2g28040fc61003241129hcd626416m648b402d0b3534c8@mail.gmail.com>
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? 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. 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 Wednesday, 24 March 2010 18:29:58 UTC