On 6/23/10 9:50 AM, Jian Li wrote:
I think encoding the security origin in the URL allows the UAs to do
the security origin check in place, without routing through other
authority to get the origin information that might cause the check
taking long time to finish.
If we worry about showing
On Tue, Jun 22, 2010 at 8:56 PM, Adrian Bateman adria...@microsoft.comwrote:
On Tuesday, June 22, 2010 8:40 PM, David Levin wrote:
I agree with you Adrian that it makes sense to let the user agent figure
out the optimal way of implementing origin and other checks.
A logical step from
I think encoding the security origin in the URL allows the UAs to do the
security origin check in place, without routing through other authority to
get the origin information that might cause the check taking long time to
finish.
If we worry about showing the double schemes in the URL, we can
On Friday, June 11, 2010 11:18 AM, Jonas Sicking wrote:
On Fri, Jun 11, 2010 at 11:11 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 11, 2010 at 9:09 AM, Adrian Bateman adria...@microsoft.com
It's not clear to me the benefit of encoding the origin into the URL. Do
we expect script to
On 6/22/10 8:44 AM, Adrian Bateman wrote:
On Friday, June 11, 2010 11:18 AM, Jonas Sicking wrote:
On Fri, Jun 11, 2010 at 11:11 AM, Jonas Sickingjo...@sicking.cc wrote:
On Fri, Jun 11, 2010 at 9:09 AM, Adrian Batemanadria...@microsoft.com
It's not clear to me the benefit of
On Tuesday, June 22, 2010 3:37 PM, Arun Ranganathan wrote:
On 6/22/10 8:44 AM, Adrian Bateman wrote:
I think it makes more sense for the URL to be opaque and let user
agents figure
out the optimal way of implementing origin and other checks.
I think it may be important to define:
*
On Tue, Jun 22, 2010 at 7:58 PM, Adrian Bateman adria...@microsoft.comwrote:
On Tuesday, June 22, 2010 3:37 PM, Arun Ranganathan wrote:
On 6/22/10 8:44 AM, Adrian Bateman wrote:
I think it makes more sense for the URL to be opaque and let user
agents figure
out the optimal way of
On Tuesday, June 22, 2010 8:40 PM, David Levin wrote:
I agree with you Adrian that it makes sense to let the user agent figure
out the optimal way of implementing origin and other checks.
A logical step from that premise is that the choice/format of the
namespace specific string should be
On Sun, Jun 13, 2010 at 10:46 PM, Mark Seaborn mseab...@chromium.org wrote:
On Wed, Jun 2, 2010 at 5:06 PM, Jian Li jia...@chromium.org wrote:
I have one question regarding the scheme for Blob.url. The latest spec
says that The proposed URL scheme is filedata:. Mozilla already ships with
On Mon, Jun 14, 2010 at 11:35 AM, Mark Seaborn mseab...@chromium.org wrote:
On Mon, Jun 14, 2010 at 12:40 AM, Jonas Sicking jo...@sicking.cc wrote:
On Sun, Jun 13, 2010 at 10:46 PM, Mark Seaborn mseab...@chromium.org
wrote:
Why do the filedata: URLs need to apply a same-origin check? It
On Fri, Jun 11, 2010 at 10:04 PM, Michael Nordman micha...@google.com wrote:
Another advantage is that...
blobdata://http_responsible_party.org:80/3699b4a0-e43e-4cec-b87b-82b6f83dd752
... makes it clear to the end user who the responsible party is when these
urls are visible in the user
On Wed, Jun 2, 2010 at 5:06 PM, Jian Li jia...@chromium.org wrote:
I have one question regarding the scheme for Blob.url. The latest spec says
that The proposed URL scheme is filedata:. Mozilla already ships with
moz-filedata:. Since the URL is now part of the Blob and it could be used
to
On Wednesday, June 02, 2010 5:27 PM, Arun Ranganathan wrote:
On 6/2/10 5:06 PM, Jian Li wrote:
Indeed, the URL scheme seems to be more sort of implementation details.
Different browser vendors can choose the appropriate scheme, like Mozilla
ships with moz-filedata. How do you think?
On Wednesday, June 02, 2010 5:35 PM, Jonas Sicking wrote:
On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 5:06 PM, Jian Li wrote:
In addition,
we're thinking it will probably be a good practice to encode the security
origin in the blob URL scheme, like
One benefit of using the encoded origin is to do the security origin check
in place, instead of resorting to a centralized authority, esp. under
multi-process architecture. Considering getting and checking the origin
before hitting the cache for the blob.url item.
On Fri, Jun 11, 2010 at 9:09
On Fri, Jun 11, 2010 at 9:09 AM, Adrian Bateman adria...@microsoft.com wrote:
On Wednesday, June 02, 2010 5:35 PM, Jonas Sicking wrote:
On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 5:06 PM, Jian Li wrote:
In addition,
we're thinking it will probably be
On Fri, Jun 11, 2010 at 11:11 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 11, 2010 at 9:09 AM, Adrian Bateman adria...@microsoft.com
wrote:
On Wednesday, June 02, 2010 5:35 PM, Jonas Sicking wrote:
On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10
Another advantage is that...
blobdata://
http_responsible_party.org:80/3699b4a0-e43e-4cec-b87b-82b6f83dd752
... makes it clear to the end user who the responsible party is when these
urls are visible in the user interface. (location bar, tooltips, etc).
On Fri, Jun 11, 2010 at 11:11 AM, Jonas
Arun:
In the latest version of the spec I see that readAsDataURL, alone
among the readAs* methods, still takes a File rather than a Blob. Is
that just an oversight, or is that an intentional restriction?
Eric
On Thu, May 13, 2010 at 5:27 AM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 3:42 PM, Eric Uhrhane wrote:
Arun:
In the latest version of the spec I see that readAsDataURL, alone
among the readAs* methods, still takes a File rather than a Blob. Is
that just an oversight, or is that an intentional restriction?
That's intentional; readAsDataURL was cited
On Wed, Jun 2, 2010 at 3:44 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 3:42 PM, Eric Uhrhane wrote:
Arun:
In the latest version of the spec I see that readAsDataURL, alone
among the readAs* methods, still takes a File rather than a Blob. Is
that just an oversight, or is that an
On 6/2/10 3:48 PM, Eric Uhrhane wrote:
Sure, why not? Why would this be limited to File objects?
A File is supposed to refer to an actual file on the local hard drive.
A Blob is a big bunch of data that you might want to do something
with. There's nothing special about a File when it comes
On Wed, Jun 2, 2010 at 3:48 PM, Eric Uhrhane er...@google.com wrote:
On Wed, Jun 2, 2010 at 3:44 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 3:42 PM, Eric Uhrhane wrote:
Arun:
In the latest version of the spec I see that readAsDataURL, alone
among the readAs* methods,
On Wed, Jun 2, 2010 at 3:57 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 3:48 PM, Eric Uhrhane wrote:
Sure, why not? Why would this be limited to File objects?
A File is supposed to refer to an actual file on the local hard drive.
A Blob is a big bunch of data that you might want
Hi, Arun,
I have one question regarding the scheme for Blob.url. The latest spec says
that The proposed URL scheme is filedata:. Mozilla already ships with
moz-filedata:. Since the URL is now part of the Blob and it could be used
to refer to both file data blob and binary data blob, should we
On Wed, Jun 2, 2010 at 3:42 PM, Eric Uhrhane er...@google.com wrote:
Arun:
In the latest version of the spec I see that readAsDataURL, alone
among the readAs* methods, still takes a File rather than a Blob. Is
that just an oversight, or is that an intentional restriction?
Having
On 6/2/10 5:06 PM, Jian Li wrote:
Hi, Arun,
I have one question regarding the scheme for Blob.url. The latest spec says
that The proposed URL scheme is filedata:. Mozilla already ships with
moz-filedata:. Since the URL is now part of the Blob and it could be used
to refer to both file data blob
I got what you mean. Thanks for clarifying it.
Do you plan to add the origin encoding into the spec? How about using more
generic scheme name blobdata:?
Jian
On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 5:06 PM, Jian Li wrote:
Hi, Arun,
I have one
On Wed, Jun 2, 2010 at 5:26 PM, Arun Ranganathan a...@mozilla.com wrote:
On 6/2/10 5:06 PM, Jian Li wrote:
Hi, Arun,
I have one question regarding the scheme for Blob.url. The latest spec
says
that The proposed URL scheme is filedata:. Mozilla already ships with
moz-filedata:. Since the
On May 21, 2010, at 00:41 , Jonas Sicking wrote:
On Thu, May 20, 2010 at 2:53 PM, Nathan nat...@webr3.org wrote:
If the scope of the identifiers is limited to a single ua, on a single
machine, and specific to that single ua (as in I can't expect to request the
identifier outside of the ua that
Jonas Sicking wrote:
On Wed, May 19, 2010 at 1:09 PM, Arun Ranganathan a...@mozilla.com wrote:
3. The renaming of the property to 'url' also suggests that we should
cease to consider an urn:uuid scheme.
I'm not sure that one follows from the other. The property's called 'url'
because that's
On Thu, May 20, 2010 at 2:53 PM, Nathan nat...@webr3.org wrote:
Jonas Sicking wrote:
On Wed, May 19, 2010 at 1:09 PM, Arun Ranganathan a...@mozilla.com
wrote:
3. The renaming of the property to 'url' also suggests that we should
cease to consider an urn:uuid scheme.
I'm not sure that one
On Tue, May 18, 2010 at 2:56 PM, Arun Ranganathan a...@mozilla.com wrote:
On 5/18/10 2:35 PM, Eric Uhrhane wrote:
On Mon, May 17, 2010 at 3:37 PM, Dmitry Titovdim...@chromium.org
wrote:
I have couple of questions, mostly clarifications I think:
1. FileReader takes Blob but there are
On 19/05/10 08:00, Darin Fisher wrote:
It doesn't seem too late to change the name. FF could support both
FileReader and BlobReader. One could just be an alias for the other.
It seems like we have situations like this frequently when it comes to
new web platform APIs. A name only becomes
Hi Arun,
On May 13, 2010, at 14:27 , Arun Ranganathan wrote:
I have updated the editor's draft of the File API to reflect changes that
have been in discussion.
Cool, thanks!
ArrayBuffers, and affiliated Typed Array views of data, are specified in a
working draft as a part of the WebGL
Robin,
ArrayBuffers, and affiliated Typed Array views of data, are specified in a
working draft as a part of the WebGL work [1]. This work has been proposed to ECMA's
TC-39 WG as well. We intend to implement some of this in the Firefox 4 timeframe, and
have reason to believe other browsers
On Wed, May 19, 2010 at 1:09 PM, Arun Ranganathan a...@mozilla.com wrote:
3. The renaming of the property to 'url' also suggests that we should
cease to consider an urn:uuid scheme.
I'm not sure that one follows from the other. The property's called 'url'
because that's what will be familiar
On Mon, May 17, 2010 at 3:37 PM, Dmitry Titov dim...@chromium.org wrote:
I have couple of questions, mostly clarifications I think:
1. FileReader takes Blob but there are multiple hints that the blob should
be actually a 'file'. As we see Blob concept grows in popularity with such
specs as
On Fri, May 14, 2010 at 11:52 AM, Arun Ranganathan a...@mozilla.com wrote:
On 5/13/10 9:32 PM, Darin Fisher wrote:
Glad to hear that you didn't intend sync access :-)
I have thoughts on Blob and how it should behave (and about the inheritance
relationship between Blob and File), which is
On 5/18/10 2:35 PM, Eric Uhrhane wrote:
On Mon, May 17, 2010 at 3:37 PM, Dmitry Titovdim...@chromium.org wrote:
I have couple of questions, mostly clarifications I think:
1. FileReader takes Blob but there are multiple hints that the blob should
be actually a 'file'. As we see Blob concept
On Tue, May 18, 2010 at 2:56 PM, Arun Ranganathan a...@mozilla.com wrote:
On 5/18/10 2:35 PM, Eric Uhrhane wrote:
On Mon, May 17, 2010 at 3:37 PM, Dmitry Titovdim...@chromium.org
wrote:
I have couple of questions, mostly clarifications I think:
1. FileReader takes Blob but there are
On 5/13/10 9:32 PM, Darin Fisher wrote:
Glad to hear that you didn't intend sync access :-)
I have thoughts on Blob and how it should behave (and about the
inheritance relationship between Blob and File), which is why I left the
unfortunate error in the editor's draft for now (commented
Greetings WebApps WG,
I have updated the editor's draft of the File API to reflect changes
that have been in discussion.
http://dev.w3.org/2006/webapi/FileAPI
Notably:
1. Blobs now allow further binary data operations by exposing an
ArrayBuffer property that represents the Blob.
On 5/13/10 7:37 AM, David Levin wrote:
On Thu, May 13, 2010 at 5:27 AM, Arun Ranganathana...@mozilla.com wrote:
Greetings WebApps WG,
I have updated the editor's draft of the File API to reflect changes that
have been in discussion.
http://dev.w3.org/2006/webapi/FileAPI
Notably:
1.
On 5/13/10 7:37 AM, David Levin wrote:
On Thu, May 13, 2010 at 5:27 AM, Arun Ranganathana...@mozilla.com wrote:
Greetings WebApps WG,
I have updated the editor's draft of the File API to reflect changes that
have been in discussion.
http://dev.w3.org/2006/webapi/FileAPI
Notably:
1.
On 13 May 2010, at 13:27, Arun Ranganathan wrote:
Greetings WebApps WG,
I have updated the editor's draft of the File API to reflect changes that
have been in discussion.
http://dev.w3.org/2006/webapi/FileAPI
Notably:
1. Blobs now allow further binary data operations by exposing an
On Thu, May 13, 2010 at 1:50 PM, J Ross Nicoll j...@jrn.me.uk wrote:
On 13 May 2010, at 13:27, Arun Ranganathan wrote:
Greetings WebApps WG,
I have updated the editor's draft of the File API to reflect changes that
have been in discussion.
http://dev.w3.org/2006/webapi/FileAPI
Notably:
On 5/13/10 1:50 PM, J Ross Nicoll wrote:
On 13 May 2010, at 13:27, Arun Ranganathan wrote:
Greetings WebApps WG,
I have updated the editor's draft of the File API to reflect changes that have
been in discussion.
http://dev.w3.org/2006/webapi/FileAPI
Notably:
1. Blobs now allow further
Glad to hear that you didn't intend sync access :-)
Can you define the contentType parameter to slice better? Is that intended
to correspond to the value of a HTTP Content-Type response header? For
example, can the contentType value include a charset attribute? It might be
useful to indicate
49 matches
Mail list logo
