Anne van Kesteren wrote:
On Sat, 22 Aug 2009 11:30:18 +0200, Simon Pieters
wrote:
On Wed, 12 Aug 2009 17:22:53 +0200, Arun Ranganathan
wrote:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Maybe the attribute should be called "URL" for consistency with
HTMLDocument.URL?
An
On Sat, 22 Aug 2009 11:30:18 +0200, Simon Pieters wrote:
On Wed, 12 Aug 2009 17:22:53 +0200, Arun Ranganathan
wrote:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Maybe the attribute should be called "URL" for consistency with
HTMLDocument.URL?
And also WebSocket.URL and
On Wed, 12 Aug 2009 17:22:53 +0200, Arun Ranganathan
wrote:
Michael Nordman wrote:
>The draft says a new UUID should be 'coined' for each method
invocation.
(Why is that?) Given the coinage of a new url on each access, accessing
it
thru an attribute feels a little odd.
This should have
On Thu, 13 Aug 2009 02:02:30 +0200, Arun Ranganathan wrote:
> Anne van Kesteren wrote:
>> I think [FileData.url] also should only be available on File.
>
> This would probably be fine, although for filedata: URLs, we don't
> *need* a mediaType (we could just define octet stream or something on
Anne van Kesteren wrote:
On Wed, 12 Aug 2009 17:13:57 +0200, Arun Ranganathan wrote:
Latest draft is:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Thanks Arun!
Anne van Kesteren wrote:
I have not received any feedback on my comments as to why getAsDataURL
On Wed, 12 Aug 2009 17:13:57 +0200, Arun Ranganathan wrote:
> Latest draft is:
> http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Thanks Arun!
> Anne van Kesteren wrote:
>> I have not received any feedback on my comments as to why getAsDataURL
>> is actually needed. I still thi
Michael Nordman wrote:
>The draft says a new UUID should be 'coined' for each method invocation.
(Why is that?) Given the coinage of a new url on each access, accessing it
thru an attribute feels a little odd.
This should have been an editor's note, and not a part of the spec.
text. The "uni
Latest draft is:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Anne van Kesteren wrote:
Thanks for the update to the draft! Below some feedback:
In the table of contents the link to the filedata URL scheme is broken.
Fixed.
The Web IDL syntax needs to be updated. E.g. Fil
On Sat, Aug 8, 2009 at 6:25 AM, Anne van Kesteren wrote:
It seems useful to use the same code for people that want to display
error messages to the user, this way you can either pass the value in
the DOM event or from an exception to the same function.
>>>
>>> If you use the same con
On Fri, 07 Aug 2009 02:19:21 +0200, Jonas Sicking wrote:
For example an web HTML editor. The editor lets you wysiwyg edit the
page as well as drop in images. Dropping in images creates a element. The edited page can then be saved
in localStorage, sent to the server using XHR, or posted to a par
On Fri, Aug 7, 2009 at 3:21 PM, Jonas Sicking wrote:
> On Fri, Aug 7, 2009 at 12:23 PM, Michael Nordman
> wrote:
> >> > I think getAsURL() should become an attribute instead. E.g.
> >> >
> >> > readonly attribute DOMString localURL;
> >> >
> >> > Since it is just a reference there is no need thi
On Fri, Aug 7, 2009 at 12:23 PM, Michael Nordman wrote:
>> > I think getAsURL() should become an attribute instead. E.g.
>> >
>> > readonly attribute DOMString localURL;
>> >
>> > Since it is just a reference there is no need this needs to be
>> > asynchronous and there is also no need for it to b
On Thu, Aug 6, 2009 at 11:29 AM, Jonas Sicking wrote:
> On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesteren wrote:
> > Thanks for the update to the draft! Below some feedback:
> >
> > In the table of contents the link to the filedata URL scheme is broken.
> >
> >
> > The Web IDL syntax needs to be
On Thu, Aug 6, 2009 at 11:42 AM, Anne van Kesteren wrote:
> I meant File rather than any, yes. Oops. Also:
>
> On Thu, 06 Aug 2009 20:29:37 +0200, Jonas Sicking wrote:
>>
>> On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesteren wrote:
>>>
>>> I have not received any feedback on my comments as to why g
I meant File rather than any, yes. Oops. Also:
On Thu, 06 Aug 2009 20:29:37 +0200, Jonas Sicking wrote:
On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesteren
wrote:
I have not received any feedback on my comments as to why getAsDataURL
is actually needed. I still think it should be dropped.
Gi
On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesteren wrote:
> Thanks for the update to the draft! Below some feedback:
>
> In the table of contents the link to the filedata URL scheme is broken.
>
>
> The Web IDL syntax needs to be updated. E.g. FileList can be simply described
> as
>
> typedef sequ
On Sat, Jul 25, 2009 at 10:18 PM, Jonas Sicking wrote:
> On Thu, Jul 23, 2009 at 12:37 AM, Garrett Smith wrote:
>> On Wed, Jul 8, 2009 at 5:05 PM, Jonas Sicking wrote:
>>> On Wed, Jul 8, 2009 at 2:26 PM, Garrett Smith wrote:
On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sicking wrote:
> On Wed, Ju
Nigel Tao wrote:
I'm jumping in late to the mailing list, so I might have missed
something said earlier...
What happens if you call fileData.getAsText on a file whose contents
are not valid unicode text (either UTF-8, UTF-16, or some other
encoding)? For example, I presume that a significant fra
Michael Nordman wrote:
The BlobBuilder.append() method is central to the use-case I'm referring to.
builder.append(string data that comprises the multipart/form-data header);
builder.append(string data that comprises simple text part);
builder.append(string data that comprises the start of a bina
2009/7/22 Arun Ranganathan :
> So, currently, we provide a fileData.getAsText(fileCallback, encoding,
> error)
>
> and
>
> within fileCallback (a callback function) you can get the file's data as a
> string (say a UTF-8 encoded string, or any encoding specified by
> "encoding"); it is passed as an
On Thu, Jul 23, 2009 at 12:37 AM, Garrett Smith wrote:
> On Wed, Jul 8, 2009 at 5:05 PM, Jonas Sicking wrote:
>> On Wed, Jul 8, 2009 at 2:26 PM, Garrett Smith wrote:
>>> On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sicking wrote:
On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smith
wrote:
> On Tue
On Wed, Jul 22, 2009 at 4:44 AM, Anne van Kesteren wrote:
> On Wed, 22 Jul 2009 04:07:18 +0200, Arun Ranganathan
> wrote:
> > This still sends strings, but XHR 2[2] has got:
> >
> > void send(in ByteArray data);
> >
> > which makes me think we need a binary getter as well :)
>
> Yes, it is cal
http://code.google.com/apis/gears/api_blobbuilder.html
> This I'm less sanguine about, since the immediately desired capability is>
to work with existing system files.
The motivating usecase for this feature in Gears is to compose the body of a
POST in the multipart/form-data format, including bin
The BlobBuilder.append() method is central to the use-case I'm referring to.
builder.append(string data that comprises the multipart/form-data header);
builder.append(string data that comprises simple text part);
builder.append(string data that comprises the start of a binary part);
builder.append(
On Tue, Jul 21, 2009 at 6:20 PM, Arun Ranganathan wrote:
> Michael Nordman wrote:
>
>> The BlobBuilder.append() method is central to the use-case I'm referring
>> to.
>> builder.append(string data that comprises the multipart/form-data header);
>> builder.append(string data that comprises simple
On Wed, Jul 8, 2009 at 5:05 PM, Jonas Sicking wrote:
> On Wed, Jul 8, 2009 at 2:26 PM, Garrett Smith wrote:
>> On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sicking wrote:
>>> On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smith wrote:
On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sicking wrote:
> On Tue, Jun 3
On Wed, 22 Jul 2009 20:26:38 +0200, Michael Nordman wrote:
> Another aspect of the use case we're discussing (composing a
> multipart/form-data POST for sending vis XHR2) is NOT having to actually
> read the full contents of the file parts into memory while doing this
> composition. That wouldn't
On Wed, 22 Jul 2009 04:07:18 +0200, Arun Ranganathan wrote:
> This still sends strings, but XHR 2[2] has got:
>
> void send(in ByteArray data);
>
> which makes me think we need a binary getter as well :)
Yes, it is called responseBody at the moment. I intent to replace both with
support for Fi
Michael Nordman wrote:
On Tue, Jul 21, 2009 at 6:20 PM, Arun Ranganathan wrote:
Michael Nordman wrote:
The BlobBuilder.append() method is central to the use-case I'm referring
to.
builder.append(string data that comprises the multipart/form-data header);
builder.append(string data th
Michael Nordman wrote:
The BlobBuilder.append() method is central to the use-case I'm referring to.
builder.append(string data that comprises the multipart/form-data header);
builder.append(string data that comprises simple text part);
builder.append(string data that comprises the start of a bina
Michael Nordman wrote:
http://code.google.com/apis/gears/api_blobbuilder.html
This I'm less sanguine about, since the immediately desired capability is>
to work with existing system files.
The motivating usecase for this feature in Gears is to compose the body of a
POST in the mu
On Wed, Jul 8, 2009 at 2:26 PM, Garrett Smith wrote:
> On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sicking wrote:
>> On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smith wrote:
>>> On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sicking wrote:
On Tue, Jun 30, 2009 at 6:13 PM, Garrett Smith
wrote:
> On Tue
On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sicking wrote:
> On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smith wrote:
>> On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sicking wrote:
>>> On Tue, Jun 30, 2009 at 6:13 PM, Garrett Smith
>>> wrote:
On Tue, Jun 30, 2009 at 4:29 PM, Jonas Sicking wrote:
> On Tue
On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sicking wrote:
> So what if you're reading two parts of the file and want different
> callbacks. Say for example that you're reading data out of a video
> file and you want to read both the index of the video to see how long
> it is, as well as read read the fi
On Mon, Jul 6, 2009 at 7:18 AM, Robin Berjon wrote:
> Heya Jonas,
>
> On Jun 30, 2009, at 10:38 , Jonas Sicking wrote:
>>
>> However, what is the use case for all this power? I.e. what
>> application would want to do this? The downside of having all the
>> power and features of using events is that
On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smith wrote:
> On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sicking wrote:
>> On Tue, Jun 30, 2009 at 6:13 PM, Garrett Smith wrote:
>>> On Tue, Jun 30, 2009 at 4:29 PM, Jonas Sicking wrote:
On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smith
wrote:
>> Wit
Heya Jonas,
On Jun 30, 2009, at 10:38 , Jonas Sicking wrote:
However, what is the use case for all this power? I.e. what
application would want to do this? The downside of having all the
power and features of using events is that the syntax becomes more
complex. So we should only do it if it pro
On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sicking wrote:
> On Tue, Jun 30, 2009 at 6:13 PM, Garrett Smith wrote:
>> On Tue, Jun 30, 2009 at 4:29 PM, Jonas Sicking wrote:
>>> On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smith
>>> wrote:
> With that in mind, do you still think it makes sense to have pr
On Wed, Jul 1, 2009 at 2:22 AM, Garrett Smith wrote:
> The picasa-style example mentioned earlier uses the word "upload".
> I've not used Picasa, but it appears to read files off a local
> network.
confused. i suspect i was the one who mentioned it.
Picasa is mostly a local application. One can
On Tue, Jun 30, 2009 at 6:13 PM, Garrett Smith wrote:
> On Tue, Jun 30, 2009 at 4:29 PM, Jonas Sicking wrote:
>> On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smith wrote:
With that in mind, do you still think it makes sense to have progress
events and all the other events you are proposing?
>
On Tue, Jun 30, 2009 at 4:29 PM, Jonas Sicking wrote:
> On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smith wrote:
>>> With that in mind, do you still think it makes sense to have progress
>>> events and all the other events you are proposing?
>>
>> I've reread my message. The arguments and reasoning gi
On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smith wrote:
>> With that in mind, do you still think it makes sense to have progress
>> events and all the other events you are proposing?
>
> I've reread my message. The arguments and reasoning given for Events
> seem clear and concise. The argument for Pr
On Tue, Jun 30, 2009 at 1:38 AM, Jonas Sicking wrote:
> On Mon, Jun 29, 2009 at 11:52 PM, Garrett Smith wrote:
>> Progress-type Events are useful because the API is asynchronous.
>> What if reading the file times out?
>>
>> If an entire directory is uploaded, as in the Picasa-style example,
>> when
Aaron,
Thanks for updating the Gears documentation!
Ok, it's live now. You can check out the Blob.getBytes() method here:
http://code.google.com/apis/gears/api_blob.html
There appears to be general support for "byte ranged" FileData objects.
FileData (from which File inherits) will conta
Ok, it's live now. You can check out the Blob.getBytes() method here:
http://code.google.com/apis/gears/api_blob.html
And the new BlobBuilder object here:
http://code.google.com/apis/gears/api_blobbuilder.html
- a
On Tue, Jun 30, 2009 at 10:33 AM, Aaron Boodman wrote:
> It actually does in the
It actually does in the latest version. Blob has a getBytes() method.
You can also concatenate blobs together using a new object called a
BlobBuilder.
I'm in the process of updating the docs and will report back when done.
- a
On Tue, Jun 30, 2009 at 6:12 AM, Olli Pettay wrote:
> On 6/30/09 4:07
On 6/30/09 4:07 PM, Thomas Broyer wrote:
On Tue, Jun 30, 2009 at 2:25 PM, Olli Pettay wrote:
On 6/30/09 1:44 PM, Ian Hickson wrote:
I'd rather just have an API that lets you split a File into a
sequence(where FileData is what File inherits from) of equally
sized chunks, or something like t
On Tue, Jun 30, 2009 at 2:25 PM, Olli Pettay wrote:
> On 6/30/09 1:44 PM, Ian Hickson wrote:
>>
>> I'd rather just have an API that lets you split a File into a
>> sequence (where FileData is what File inherits from) of equally
>> sized chunks, or something like that, than something that lets you
On 6/30/09 1:44 PM, Ian Hickson wrote:
On Tue, 30 Jun 2009, Olli Pettay wrote:
File API should probably have some way to get only parts of the file.
getAsXXX(long long offset, long long length). Then uploading huge files
could be split and decoding video (or something like that) in JS might bec
On Tue, 30 Jun 2009, Olli Pettay wrote:
>
> File API should probably have some way to get only parts of the file.
> getAsXXX(long long offset, long long length). Then uploading huge files
> could be split and decoding video (or something like that) in JS might become
> possible.
> This is somethin
On 6/19/09 6:00 AM, timeless wrote:
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathan wrote:
Hixie, I think a Base64 representation of the file resource may be
sufficient, particularly for the image use case (which is how it is used
already). Can you flesh out why the new schema is a good idea
On Mon, Jun 29, 2009 at 11:52 PM, Garrett Smith wrote:
> Progress-type Events are useful because the API is asynchronous.
> What if reading the file times out?
>
> If an entire directory is uploaded, as in the Picasa-style example,
> when does the "success" callback fire?
> 1) after all files in "s
On Mon, Jun 29, 2009 at 11:14 AM, Arun Ranganathan wrote:
> Garrett,
>
> Thanks for taking the time to review this.
>
> Garrett Smith wrote:
>>
>> http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml
>> Why does the URI contain the date "2006"?
>
> It certainly is confusing, but the '2006
Garrett,
Thanks for taking the time to review this.
Garrett Smith wrote:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml
Why does the URI contain the date "2006"?
It certainly is confusing, but the '2006' persists as an artifact of the
CVS repository that I'm using to work on
On Thu, Jun 18, 2009 at 6:13 PM, Arun Ranganathan wrote:
> Boris Zbarsky wrote:
>>
>> Ian Hickson wrote:
>>>
>>> Local display of images before uploading them requires being able to take
>>> a File object and poke it into parts of the platform that currently only
>>> take URLs. I suggest that the w
2009/6/25 Arun Ranganathan :
> Giovanni,
>
>> For what concerns the "file as URI" feature:
>> What about reusing the "cid" scheme?
>>
>>
>
> This is an intriguing idea. Other ideas I've experimented with include
> filedata:// but since cid has seen some usage (e.g. within email), it might
> be a g
Giovanni,
For what concerns the "file as URI" feature:
What about reusing the "cid" scheme?
This is an intriguing idea. Other ideas I've experimented with include
filedata:// but since cid has seen some usage (e.g. within email), it
might be a good candidate.
Upon reflection, the resear
Ojan Vafai wrote:
What are the "URL length limitations imposed by user agents"?
A quick search does not show any hard limits outside of IE's ~2k
limit. Presumably
IE could be convinced to increase that for data URLs.
Firefox allows up to 2GB.
IE8 support for Data URLs is documented here:
On Fri, 19 Jun 2009, Jonas Sicking wrote:
>
> The problems that seems like they need to be solved are security (are
> these URIs accessible by any domain), and lifetime (how long does the
> URI work).
The security would be that the origin of these URLs is fixed to be the
origin of the script c
On Fri, Jun 19, 2009 at 2:10 PM, Jonas Sicking wrote:
> On Thu, Jun 18, 2009 at 8:30 PM, Ian Hickson wrote:
> >> On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathan
> wrote:
> >> > Hixie, I think a Base64 representation of the file resource may be
> >> > sufficient, particularly for the image use c
On Thu, Jun 18, 2009 at 8:30 PM, Ian Hickson wrote:
> On Fri, 19 Jun 2009, timeless wrote:
>> On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathan wrote:
>> > Hixie, I think a Base64 representation of the file resource may be
>> > sufficient, particularly for the image use case (which is how it is use
Robin Berjon wrote:
On Jun 19, 2009, at 10:16 , Anne van Kesteren wrote:
On Fri, 19 Jun 2009 01:01:41 +0200, Arun Ranganathan
wrote:
Ian Hickson wrote:
I spoke with the developers of one of these Well-Known Web
Applications, and they didn't even _mention_ the styling difficulties
of as one o
On Jun 19, 2009, at 10:16 , Anne van Kesteren wrote:
On Fri, 19 Jun 2009 01:01:41 +0200, Arun Ranganathan
wrote:
Ian Hickson wrote:
I spoke with the developers of one of these Well-Known Web
Applications, and they didn't even _mention_ the styling
difficulties
of as one of the reasons for
On Jun 19, 2009, at 05:30 , Ian Hickson wrote:
On Fri, 19 Jun 2009, timeless wrote:
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathan
wrote:
Hixie, I think a Base64 representation of the file resource may be
sufficient, particularly for the image use case (which is how it
is used
already).
For what concerns the "file as URI" feature:
What about reusing the "cid" scheme?
- It would avoid collisions, as anything can be used as Content-ID,
including a progressive number or the name of the input element
- It would not be problematic to implement, as "cid" URIs are already
supported by b
On Fri, 19 Jun 2009 01:01:41 +0200, Arun Ranganathan wrote:
> Ian Hickson wrote:
>> I spoke with the developers of one of these Well-Known Web
>> Applications, and they didn't even _mention_ the styling difficulties
>> of as one of the reasons for using Flash here.
>
> This feedback is extrem
On Fri, 19 Jun 2009, timeless wrote:
> On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathan wrote:
> > Hixie, I think a Base64 representation of the file resource may be
> > sufficient, particularly for the image use case (which is how it is used
> > already). Can you flesh out why the new schema is
On Thursday, June 18, 2009 6:13 PM, Arun Ranganathan wrote:
> Boris Zbarsky wrote:
> > Ian Hickson wrote:
> >> Local display of images before uploading them requires being able to
> >> take a File object and poke it into parts of the platform that
> >> currently only take URLs. I suggest that the w
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathan wrote:
> Hixie, I think a Base64 representation of the file resource may be
> sufficient, particularly for the image use case (which is how it is used
> already). Can you flesh out why the new schema is a good idea?
so. I have folders with 100-100
Boris Zbarsky wrote:
Ian Hickson wrote:
Local display of images before uploading them requires being able to
take a File object and poke it into parts of the platform that
currently only take URLs. I suggest that the way we address this is
by adding an API to a File object that returns a URL l
Ian Hickson wrote:
Local display of images before uploading them requires being able to take
a File object and poke it into parts of the platform that currently only
take URLs. I suggest that the way we address this is by adding an API to a
File object that returns a URL like this:
scheme:
Ian Hickson wrote:
On Thu, 18 Jun 2009, Arun Ranganathan wrote:
I think FileDialog is a bad idea. We already have UI for selecting
multiple files: . (And soon with
DataTransfer.files we have a second one.) I would much rather wait
with FileDialog until it is very clear that we need it. It s
On Thu, 18 Jun 2009, Arun Ranganathan wrote:
> >
> > I think FileDialog is a bad idea. We already have UI for selecting
> > multiple files: . (And soon with
> > DataTransfer.files we have a second one.) I would much rather wait
> > with FileDialog until it is very clear that we need it. It seems
Anne van Kesteren wrote:
I would prefer it if fileName and fileSize were simply named name and size
instead. It should be clear from the object what they mean.
OK.
I think it would be better if the FileError object was not modeled after the
DOMException interface. Making it consistent wit
74 matches
Mail list logo
