Re: [FileAPI] Blob.URN?
Thanks for the explanation. The getURN method is an interesting proposal.
It seems useful even when you do have a File because you might want to
force the file contents to be loaded as a particular media type.
-Darin
On Tue, Mar 23, 2010 at 7:40 PM, Michael Nordman micha...@google.comwrote:
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.htmlsnip
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
On Tue, Mar 23, 2010 at 7:19 PM, Dmitry Titov dim...@google.com wrote:
Blob would need a content-type for that, but it could probably easy be
added as a property that is assignable.
BTW if the Blob could have a urn and mime type, this info could be
directly used to form the headers for the Blob when sending it in multipart
form using FormData.
Dmitry
On Tue, Mar 23, 2010 at 2:23 PM, Darin Fisher da...@chromium.org wrote:
Apologies if this has been discussed before, but I'm curious why URN is
not a property of Blob. It seems like it would be useful to be able to load
a slice of a File. For example, this could be used by an application to
fetch all of its subresources out of a single file.
-Darin
Re: Adding Content-Disposition header to File.urn response
The Blob.getURN proposal from Eric Uhrhane might be a better way to solve the C-D issue: http://www.mail-archive.com/public-webapps@w3.org/msg06137.html It would give the user the ability to control whether a URN loaded into an IFRAME triggers a download or not. -Darin On Tue, Mar 23, 2010 at 4:57 PM, Jian Li jia...@chromium.org wrote: Hi, We probably have already discussed this: adding the Content-Disposition header into the response when reading File.urn resource. But since this is not currently documented in the spec, I want to ping you guys to make sure we are all in the same page. When the header Content-Dispositon: attachment is added, the UA could either trigger the inline replacement or initiate the download depending on the different element type. For IMG/INPUT/VIDEO/SCRIPT/LINK, our UA is doing the replacement inline. For others like IFRAME/LOCATION, our UA will initiate the download. Are these behaviors you also expect for your UA? In addition, do we want to add the file name to the C-D header? I've heard that there is a discussion on setting C-D header pragmatically. Do we want to go along this way? Thanks, Jian
Re: [FileAPI] Blob.URN?
On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman micha...@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.htmlsnip
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/
Re: [XHR2] term flag, for authors
On Wed, 24 Mar 2010 04:24:45 +0100, Sebastián Ramírez sebast...@artedemagia.com wrote: I want to know if I am understanding or misinterpreting the spec and what, by the spec, is what I'm supposed to be able to use. Everything that authors can use is expressed in the Web IDL fragment. Everything outside of that represents some kind of data implementations need to keep around one way or another to properly implement the specification. -- Anne van Kesteren http://annevankesteren.nl/
Re: FormData with sliced Blob
On Tue, 23 Mar 2010 22:22:37 +0100, Darin Fisher da...@chromium.org wrote: Why couldn't FormData.append(Blob) provide optional parameters to allow the caller to specify the name and type? Why wouldn't you provide a File object instead then? It seems a lot of use cases here and elsewhere would be addressed by having a way to get a File out of a Blob. -- Anne van Kesteren http://annevankesteren.nl/
Re: [Notifications] feedback requested on new Editor's Draft
On Tue, Mar 23, 2010 at 4:53 PM, Ryan Seddon seddon.r...@gmail.com wrote: On Tue, Mar 23, 2010 at 1:06 PM, John Gregg john...@google.com wrote: After the extensive discussion several weeks ago, I've been working on a new draft for Web Notifications which is now available at http://dev.w3.org/2006/webapi/WebNotifications/publish/ Not sure if this has been asked before but what about an optional property to position it elsewhere beside the bottom left. Something like: createNotification(in DOMString iconUrl, in DOMString title, in DOMString body[, in DOMString position]) Where it can take 4 possible values: topleft, topright, bottomleft, bottomright. Bottomright being the default. Do you have a use case in mind for this? Perhaps there is one on a particular device, but for most of the browser/desktop use cases I think it is preferable to leave it up to the user agent or the underlying notification platform to decide where to put the notifications (probably based on user preferences). Should we really put another interface on the global object? Can we not put these on window.navigator like other APIs that integrate with the system layer? I also agree that it would make sense to add it to navigator. Sounds like there is consensus on that. I will move it there. -John
Re: [XHR2] term flag, for authors
Many thanks. El 24 de marzo de 2010 05:54, Anne van Kesteren ann...@opera.com escribió: On Wed, 24 Mar 2010 04:24:45 +0100, Sebastián Ramírez sebast...@artedemagia.com wrote: I want to know if I am understanding or misinterpreting the spec and what, by the spec, is what I'm supposed to be able to use. Everything that authors can use is expressed in the Web IDL fragment. Everything outside of that represents some kind of data implementations need to keep around one way or another to properly implement the specification. -- Anne van Kesteren http://annevankesteren.nl/
Re: FormData with sliced Blob
On Wed, Mar 24, 2010 at 2:55 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 23 Mar 2010 22:22:37 +0100, Darin Fisher da...@chromium.org wrote: Why couldn't FormData.append(Blob) provide optional parameters to allow the caller to specify the name and type? Why wouldn't you provide a File object instead then? It seems a lot of use cases here and elsewhere would be addressed by having a way to get a File out of a Blob. That's a very interesting idea. I hadn't considered the possibility of creating a File from a Blob. I guess that would imply having a File object that is not necessarily backed by an on-disk representation. Obviously, there was nothing promising that before. Your proposal sounds reasonable to me. -Darin -- Anne van Kesteren http://annevankesteren.nl/
Re: [FileAPI] Blob.URN?
Wouldn't it be better to have a constructor for File. File(Blob, name,
type, contentdisposition).
That could work, not sure its as intuitive. I think Files are destined to be
more often returned by various APIs and less often constructed by
application code directly. Wrapping a File/Blob in another File in order to
'override' whatever content-headers are baked into the original feels less
direct then specifying how you want the browser to view the File when given
a particular URL.
Mutable properties of the File object would be confusing. For example, does
setting the 'name' attribute rename the underlying file or tweeking type put
a new extension on the file name? The answer is no, but its easy to see how
somebody may expect that behavior.
I'd also like to point out that a getURL() method with an option to specify
the content -headers is compatible with a .url attribute that produces a URL
that will result in 'default' content-headers for the underlying File.
Also, didn't we decide to change URN to URL? As far as I can tell that is
how Gecko is implementing it.
That may be, I dug this snippet up from an discussion long ago.
On Wed, Mar 24, 2010 at 1:58 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman micha...@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.htmlsnip
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/
Re: [FileAPI] Blob.URN?
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 ann...@opera.com wrote:
On Wed, 24 Mar 2010 03:40:36 +0100, Michael Nordman micha...@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.htmlsnip
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/
RE: VMMF - new version
Hi Robin, I'm not sure how far forward we are with this but looking at the security considerations, it would be useful to have the examples for implementers to understand where we're coming from with the concerns. For your info, this was the original proposal I discussed with Marcin: Security Considerations Widgets could be intentionally designed to visually dupe or confuse the user for social engineering purposes. Some methods that could be used to perform this could be by creating: * widgets that the user cannot see (full-screen invisible widgets in front of other things on the screen, such as a PIN-code entry) * widgets that have a size smaller than the user can reasonably see (e.g. a 1px x 1px widget) * widgets that have no chrome that could masquerade as some other existing object on the screen (for example a lock and key) Implementers of this specification are asked to take these points into account and design appropriate measures to safeguard the user. Thanks, David. -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Robin Berjon Sent: 04 March 2010 13:13 To: public-webapps WG Subject: VMMF - new version Hi all, I just produced an update of VMMF to make it ready for publication: http://dev.w3.org/2006/waf/widgets-vmmf/. Essentially I changed it so that it corresponds to CSS Media Queries. That, plus it being a UI oriented specification, means that there's only one normative assertion and it's a SHOULD. Comments welcome, I think that this baby can ship. -- Robin Berjon - http://berjon.com/
Re: [web databases] SQLStatementErrorCallback
On Mon, Nov 30, 2009 at 7:07 PM, Ian Hickson i...@hixie.ch wrote: On Fri, 4 Sep 2009, Dumitru Daniliuc wrote: When talking about statement error callbacks (point #6, section 4.3.2), the spec says: 1. If the error callback returns false, then move on to the next statement, if any, or onto the next overall step otherwise. 2. Otherwise, the error callback did not return false, or there was no error callback. Jump to the last step in the overall steps. What should happen if the callback doesn't return anything (undefined)? Should we jump to the transaction error callback? Can/should we clarify this in the spec too? If it doesn't return false, then the second step you quote above (numbered 3 in the spec) applies, no? I don't understand how this is unclear. I had misunderstood the question above. For the record, when a callback defined in the IDL to return a boolean actually returns a non-boolean value, it is my understanding that WebIDL requires that ToBoolean() be applied to the return value. So returning nothing or undefined is equivalent to returning false. Sorry about the miscommunication here. -- Ian Hickson
Re: [web databases] SQLStatementErrorCallback
On Thu, 25 Mar 2010 01:39:42 +0100, Ian Hickson i...@hixie.ch wrote: For the record, when a callback defined in the IDL to return a boolean actually returns a non-boolean value, it is my understanding that WebIDL requires that ToBoolean() be applied to the return value. So returning nothing or undefined is equivalent to returning false. Oh, this is serious. Isn't this clarified in the WebIDL ? If not then it *must* be.
