Anne van Kesteren wrote:
On Sat, 22 Aug 2009 11:30:18 +0200, Simon Pieters sim...@opera.com
wrote:
On Wed, 12 Aug 2009 17:22:53 +0200, Arun Ranganathan
a...@mozilla.com wrote:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.html
Maybe the attribute should be called URL for
On Thu, 13 Aug 2009 02:02:30 +0200, Arun Ranganathan a...@mozilla.com 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
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.
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
Anne van Kesteren wrote:
On Wed, 12 Aug 2009 17:13:57 +0200, Arun Ranganathan a...@mozilla.com 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
On Sat, Aug 8, 2009 at 6:25 AM, Anne van Kesterenann...@opera.com 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
On Thu, Aug 6, 2009 at 11:29 AM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@opera.com 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
On Fri, Aug 7, 2009 at 3:21 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Aug 7, 2009 at 12:23 PM, Michael Nordmanmicha...@google.com
wrote:
I think getAsURL() should become an attribute instead. E.g.
readonly attribute DOMString localURL;
Since it is just a reference there
On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@opera.com 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
I meant File rather than any, yes. Oops. Also:
On Thu, 06 Aug 2009 20:29:37 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@opera.com
wrote:
I have not received any feedback on my comments as to why getAsDataURL
is actually needed. I still
On Thu, Aug 6, 2009 at 11:42 AM, Anne van Kesterenann...@opera.com wrote:
I meant File rather than any, yes. Oops. Also:
On Thu, 06 Aug 2009 20:29:37 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Aug 6, 2009 at 4:04 AM, Anne van Kesterenann...@opera.com wrote:
I have not received any
2009/7/22 Arun Ranganathan a...@mozilla.com:
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
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
On Wed, 22 Jul 2009 04:07:18 +0200, Arun Ranganathan a...@mozilla.com 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
On Wed, 22 Jul 2009 20:26:38 +0200, Michael Nordman micha...@google.com 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
On Wed, Jul 8, 2009 at 5:05 PM, Jonas Sickingjo...@sicking.cc wrote:
On Wed, Jul 8, 2009 at 2:26 PM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sickingjo...@sicking.cc wrote:
On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On
On Wed, Jul 22, 2009 at 4:44 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 22 Jul 2009 04:07:18 +0200, Arun Ranganathan a...@mozilla.com
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
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
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);
On Tue, Jul 21, 2009 at 6:20 PM, Arun Ranganathan a...@mozilla.com 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
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
On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sickingjo...@sicking.cc wrote:
On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Jun 30, 2009 at 6:13 PM, Garrett Smithdhtmlkitc...@gmail.com
wrote:
On
On Wed, Jul 8, 2009 at 2:26 PM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sickingjo...@sicking.cc wrote:
On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sickingjo...@sicking.cc wrote:
On
On Wed, Jul 1, 2009 at 9:01 PM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Tue, Jun 30, 2009 at 7:36 PM, Jonas Sickingjo...@sicking.cc wrote:
On Tue, Jun 30, 2009 at 6:13 PM, Garrett Smithdhtmlkitc...@gmail.com wrote:
On Tue, Jun 30, 2009 at 4:29 PM, Jonas Sickingjo...@sicking.cc wrote:
On
On Mon, Jul 6, 2009 at 7:18 AM, Robin Berjonro...@berjon.com 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
On Mon, Jul 6, 2009 at 1:38 PM, Jonas Sickingjo...@sicking.cc 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
On Wed, Jul 1, 2009 at 2:22 AM, Garrett Smith dhtmlkitc...@gmail.com 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
On Mon, Jun 29, 2009 at 11:14 AM, Arun Ranganathana...@mozilla.com 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
On Mon, Jun 29, 2009 at 11:52 PM, Garrett Smithdhtmlkitc...@gmail.com 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
On 6/19/09 6:00 AM, timeless wrote:
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com 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
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 something we
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
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
sequenceFileData (where FileData is what File inherits from) of equally
sized chunks, or something like that, than something that lets you
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
sequenceFileData(where FileData is what File inherits from) of equally
sized chunks, or
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 Pettayolli.pet...@helsinki.fi
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 Boodmana...@google.com wrote:
It
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
On Tue, Jun 30, 2009 at 1:38 AM, Jonas Sickingjo...@sicking.cc wrote:
On Mon, Jun 29, 2009 at 11:52 PM, Garrett Smithdhtmlkitc...@gmail.com 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
On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smithdhtmlkitc...@gmail.com 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
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 Ranganathana...@mozilla.com 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
On Fri, 19 Jun 2009 01:01:41 +0200, Arun Ranganathan a...@mozilla.com 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 input type=file as one of the reasons for using Flash here.
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
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 Ranganathana...@mozilla.com
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
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
a...@mozilla.com 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
On Thu, Jun 18, 2009 at 8:30 PM, Ian Hicksoni...@hixie.ch wrote:
On Fri, 19 Jun 2009, timeless wrote:
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com wrote:
Hixie, I think a Base64 representation of the file resource may be
sufficient, particularly for the image use case
On Fri, Jun 19, 2009 at 2:10 PM, Jonas Sicking jo...@sicking.cc wrote:
On Thu, Jun 18, 2009 at 8:30 PM, Ian Hicksoni...@hixie.ch wrote:
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com
wrote:
Hixie, I think a Base64 representation of the file resource may be
sufficient,
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
It's really great that this is finally moving forward! Here are some
preliminary comments on the current draft:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml
I would prefer it if fileName and fileSize were simply named name and size
instead. It should be clear from the
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
On Thu, 18 Jun 2009, Arun Ranganathan wrote:
I think FileDialog is a bad idea. We already have UI for selecting
multiple files: input type=file multiple. (And soon with
DataTransfer.files we have a second one.) I would much rather wait
with FileDialog until it is very clear that we
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: input type=file multiple. (And soon with
DataTransfer.files we have a second one.) I would much rather wait
with FileDialog until it is very
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:
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
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com 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
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 way we
On Fri, 19 Jun 2009, timeless wrote:
On Fri, Jun 19, 2009 at 4:13 AM, Arun Ranganathana...@mozilla.com 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
57 matches
Mail list logo
