On Tue, Nov 17, 2009 at 9:12 PM, Julian Reschke julian.resc...@gmx.de wrote:
3. We could not directly call out a URI scheme at all. The benefit of
doing this is we can specify *behavior* without actually getting into
details about the actual identifier scheme used. But, the chief reason to
Jonas Sicking wrote:
On Tue, Nov 17, 2009 at 9:12 PM, Julian Reschke julian.resc...@gmx.de wrote:
3. We could not directly call out a URI scheme at all. The benefit of
doing this is we can specify *behavior* without actually getting into
details about the actual identifier scheme used. But,
On Wed, 18 Nov 2009 01:03:23 +0100, Arun Ranganathan a...@mozilla.com
wrote:
1. We could coin a new scheme such as the originally proposed filedata:
scheme. This has the advantages of associating behavior (and semantics)
with a scheme, so that existing schemes aren't confused or co-opted
Robin Berjon wrote:
...
Couldn't we just register a URN NID for this? It seems that one has to go
through fewer hurdles, and no matter how transient I believe that it's a useful
thing to identify.
...
Yes, that's possible and probably would cause less eyebrows being raised...
BR, Julian
On Nov 18, 2009, at 13:13 , Julian Reschke wrote:
Robin Berjon wrote:
...
Couldn't we just register a URN NID for this? It seems that one has to go
through fewer hurdles, and no matter how transient I believe that it's a
useful thing to identify.
...
Yes, that's possible and probably
On Tue, Nov 17, 2009 at 6:25 PM, Arun Ranganathan a...@mozilla.com wrote:
Eric,
I recall you saying at TPAC that you wanted to keep the Blob
interface as small as possible, since it seemed likely to get used in
a lot of places. I think that's an excellent goal, but of course,
having
Julian Reschke wrote:
Arun Ranganathan wrote:
The latest revision of the FileAPI editor's draft is available here:
http://dev.w3.org/2006/webapi/FileAPI/
...
4. A suggestion to *not* have a separate scheme (filedata:) in lieu
of urn:uuid:uuid[2] has been the basis of a rewrite
Eric,
I recall you saying at TPAC that you wanted to keep the Blob
interface as small as possible, since it seemed likely to get used in
a lot of places. I think that's an excellent goal, but of course,
having said that, I am immediately going to suggest that you add
something to it.
Arun Ranganathan wrote:
Is there a particular reason why a specific URI scheme needs to be
called out at all?
(there are other schemes that may be more flexible, for instance
because they allow using a UUID/String pair for identification).
This is a useful question to answer :)
I assume
want to suggest that
this slow anything else down.
Eric
[1] http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0424.html
On Mon, Oct 26, 2009 at 4:24 AM, Arun Ranganathan a...@mozilla.com wrote:
The latest revision of the FileAPI editor's draft is available here:
http://dev.w3
On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:
On Mon, Nov 2, 2009 at 12:25 PM, Adrian Bateman
adria...@microsoft.com wrote:
On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
But like Arun, I suspect that this feature is the most controversial
in the spec. Apple
Adrian Bateman wrote:
On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:
On Mon, Nov 2, 2009 at 12:25 PM, Adrian Bateman
adria...@microsoft.com wrote:
On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
But like Arun, I suspect that this feature is the most
On Tuesday, November 03, 2009 10:07 AM, Arun Ranganathan wrote:
Adrian Bateman wrote:
On Monday, November 02, 2009 10:12 PM, Jonas Sicking wrote:
Are you concerned about security bugs in the feature design or in
the implementation?
Mostly in the implementation - it increases the surface
On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
On Tue, Oct 27, 2009 at 12:36 AM, Ian Hickson i...@hixie.ch wrote:
I would like to see implementation feedback on this. I don't
understand
why we would want to assign semantics to urn:uuid: URLs that are so
specific -- that seems
On Mon, Nov 2, 2009 at 12:25 PM, Adrian Bateman adria...@microsoft.com wrote:
On Tuesday, October 27, 2009 2:35 PM, Jonas Sicking wrote:
On Tue, Oct 27, 2009 at 12:36 AM, Ian Hickson i...@hixie.ch wrote:
I would like to see implementation feedback on this. I don't
understand
why we would
Arun Ranganathan wrote:
The latest revision of the FileAPI editor's draft is available here:
http://dev.w3.org/2006/webapi/FileAPI/
...
4. A suggestion to *not* have a separate scheme (filedata:) in lieu of
urn:uuid:uuid[2] has been the basis of a rewrite of that feature in
this version
Le lundi 26 octobre 2009 à 05:24 -0700, Arun Ranganathan a écrit :
The latest revision of the FileAPI editor's draft is available here:
http://dev.w3.org/2006/webapi/FileAPI/
The WebIDL checker identifies a couple of simple bugs in the draft:
http://www.w3.org/2009/07/webidl-check?doc=http%3A
Dominique Hazael-Massieux wrote:
Le lundi 26 octobre 2009 à 05:24 -0700, Arun Ranganathan a écrit :
The latest revision of the FileAPI editor's draft is available here:
http://dev.w3.org/2006/webapi/FileAPI/
The WebIDL checker identifies a couple of simple bugs in the draft:
http
Jonas,
When loadend was removed from media elements [2] I wished to determine
whether it was event overkill to also fire at successful reads. Sounds
like you want it back for successful reads as well?
But the reason why loadend *and load* was removed from video do not
apply here. The
On Mon, Oct 26, 2009 at 5:24 AM, Arun Ranganathan a...@mozilla.com wrote:
The latest revision of the FileAPI editor's draft is available here:
http://dev.w3.org/2006/webapi/FileAPI/
A few comments:
* loadend should fire after load/error/abort.
* I'm not sure i love the name 'fileData'. Maybe
On Mon, 26 Oct 2009, Arun Ranganathan wrote:
2. Interface names have changed (notably FileData -- Blob) since the
underlying FileData interface had uses on the platform beyond a file
read API. Blob as an interface name was first introduced by a Google
Gears API, which I cite as an
Jonas Sicking wrote:
On Mon, Oct 26, 2009 at 5:24 AM, Arun Ranganathan a...@mozilla.com wrote:
The latest revision of the FileAPI editor's draft is available here:
http://dev.w3.org/2006/webapi/FileAPI/
A few comments:
* loadend should fire after load/error/abort.
Currently
On Tue, Oct 27, 2009 at 12:36 AM, Ian Hickson i...@hixie.ch wrote:
3. The event model resembles that of XHR2, with a few differences.
Notably, the APIs differ in their use of the 'loadend' ProgressEvent.
I think this spec needs examples. I think the examples would show that the
current design
On Tue, 27 Oct 2009, Jonas Sicking wrote:
All we're saying is that urn:uuid represents a specific chunk of data
with a specific mimetype. This seems like something that's already there
with urn:uuid.
We're also saying that urn:uuid: has special semantics in the same-origin
model, and that
On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 Oct 2009, Jonas Sicking wrote:
All we're saying is that urn:uuid represents a specific chunk of data
with a specific mimetype. This seems like something that's already there
with urn:uuid.
We're also saying that
On Tue, 27 Oct 2009, Jonas Sicking wrote:
On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 Oct 2009, Jonas Sicking wrote:
All we're saying is that urn:uuid represents a specific chunk of data
with a specific mimetype. This seems like something that's already
On Tue, Oct 27, 2009 at 3:26 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 Oct 2009, Jonas Sicking wrote:
On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 Oct 2009, Jonas Sicking wrote:
All we're saying is that urn:uuid represents a specific chunk of data
Ian Hickson wrote:
On Tue, 27 Oct 2009, Jonas Sicking wrote:
On Tue, Oct 27, 2009 at 2:49 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 27 Oct 2009, Jonas Sicking wrote:
All we're saying is that urn:uuid represents a specific chunk of data
with a specific mimetype. This seems
The latest revision of the FileAPI editor's draft is available here:
http://dev.w3.org/2006/webapi/FileAPI/
These changes constitute a substantial reworking of the original API
along the lines of the Alternative File API proposal [1]. There are
also some additional changes that are worth
29 matches
Mail list logo
