Nikunj R. Mehta wrote:
On Aug 12, 2009, at 7:29 AM, Arun Ranganathan wrote:
Gregg Tavares wrote:
How about this?
Why make a new API for getting the contents of a file (local or
otherwise)
when we already have one which is XHR?
What if FileList was just array of File objects where each
Michael Nordman wrote:
Currently we have File and FileData, where a File object ISA FileData
object... completion is delivered via readXXX method completion callbacks.
It would be easy to add progress callbacks to those readXXX methods.
I think Garrets point about two different corners of the web
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
Garrett Smith wrote:
Good to get more notice on the API, but saying things like "Arun is a
great guy" in that same entry indicates impartiality.
He's a reasonably good guy, though :-)
AISB, the "2006" uri returns the latest "editors draft" and the
"Latest public version" at "/TR/file-upload
re confusing "upload" with file
access. The '2006' and the 'FileUpload' are historical leftovers :-)
I hope to make headway on these issues by next week.
-- A*
[1] http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0565.html
[2] http://www.ietf.org/rfc
Dan Connolly wrote:
Looks like the word is getting out about this work;
there's a pretty favorable article on ajaxian.
http://ajaxian.com/archives/w3c-publish-first-working-draft-of-file-api
But it's a little confused...
"The W3C has published a working draft for the File API"
W3C hasn't actual
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
splice should synchronously return a new FileData object. No need for
asynchronous callback since no IO occurs.
Done, though I used Anne's suggestion to make it an attribute.
Whoops, no I didn't mean Anne's suggestion for slice -- I meant it for
getAsURL.
Also the current draft is:
http
Adam de Boor wrote:
this is a minor point, but I'm finding the name of the "splice" method to be
odd. To me splice means to join, and "slice" would seem a more appropriate
name. The Array object has both splice and slice, and the former is used for
removing and inserting data and modifies the arr
Jonas Sicking wrote:
A few comments:
Need to specify that all getAsX functions call the callback
*asynchronously*. Also need to integrate this with the HTML5 event
loop.
Done.
getAsBinary should be called getAsBinaryString so that once we have a
BinaryArray or some such we can add a getAsBi
Gregg Tavares wrote:
How about this?
Why make a new API for getting the contents of a file (local or otherwise)
when we already have one which is XHR?
What if FileList was just array of File objects where each File object is
just a URL in the format
"filedata: uuid, filename"
Then you can use
Garrett Smith wrote:
In glancing at some of the methods in FileAPI, I noticed some coding
errors.
There definitely were errors; thank you for catching them.
First, an overview explanation:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml#dfn-getAsDataURL
|... If the call is su
Jonas Sicking wrote:
Here is an alternative proposal for an API for reading files:
[Constructor, Implements=EventTarget]
interface FileRequest {
readAsBinaryString(in FileData filedata);
readAsText(in FileData filedata, [Optional] in DOMString);
readAsDataURL(in File file);
abort();
Gregg Tavares wrote
The File API is meant to talk to your local file system. It isn't a
"network download" API, but it seems that's what you want :-). Perhaps I am
misunderstanding your question?
Sorry, I was told on the HTML5 list that this is where network downloads and
archive suppor
Dmitry,
the spec lists a use case about a web app that needs to send file(s) to the
server programmatically. I happen to think lately about an E-mail app that
can send attachments. FileData and its splice() method are useful here. I
assume the XHR2 spec would get XHR.send(FileData) method. XHR2
Gregg Tavares wrote:
I'd really like to contribute to this as I'm helping implement WebGL and we
need a way to get LOTS of data into WebGL. Hundreds of files per app.
That said, there's a bunch of things I don't understand about the API
*) Given that XMLHttpRequest is limited to a same domain p
Garrett Smith wrote:
Please show the subsequent use cases you've studied and please do
publish your studies.
What I meant by "use cases" was this exchange:
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/0371.html
http://lists.w3.org/Archives/Public/public-webapps/2009JulSep/
I have updated the draft of the File API, and welcome more review. Note
that it is no longer called "FileUpload" since this term has become
misleading.
In particular, here are some of the issues addressed (and some not):
> Any reason you're using an XHTML file to edit this? Also, the
indent
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
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
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
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
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
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:
Doug Schepers wrote:
Hi, Nikunj-
I think Mike was overly blunt, but essentially correct in his
response, but I'd like to add a specific comment inline...
Nikunj R. Mehta wrote (on 6/24/09 8:13 PM):
On Jun 23, 2009, at 5:10 PM, Ian Hickson wrote:
The Web Storage specification is someone dead
Arthur Barstow wrote:
Members of the Web Apps WG,
Below is an email from Henry Thompson (forwarded with his permission),
on behalf of the TAG [1], re the CORS spec [2].
Two things:
1. Please respond to at least this part of Henry's mail:
[[
It appeared to us that a number of significant cri
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 a
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
Michael(tm) Smith wrote:
For those on this list who are not also on the www-tag list, this
is just a heads-up that there's an informal draft document --
titled "W3C and APIS" -- that's likely to be of some potential
interest to people following the WebApps WG work. It was written
by Ashok Malhotr
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
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
Robin,
- The indentation of your WebIDL snippets is a bit broken, which
makes them hard to read.
I've got this nit numerous times; I'm going to fix it.
- Do we want to keep FileList? I think we're all tired of those. I
know that the sequence section of WebIDL hasn't been written, but
t
Timeless,
These are all sensible nits and I'll incorporate them.
-- A*
timeless wrote:
http://dev.w3.org/2006/webapi/FileUpload/publish/FileAPI.xhtml
Note, I expect all of my comments here to be of an editorial nature.
In the Abstract:
use of appropriate [DOM]DOM methods should return a
I'd like review on the most recent draft of the File API (renamed from
"FileUpload API") [1]. There's been a great deal of interest in the
File API from different quarters[2], and I look forward to feedback on
how to represent file lists, file objects (and accessors), file
selection dialogs, a
Maciej Stachowiak wrote:
On Oct 17, 2008, at 11:46 AM, Arun Ranganathan wrote:
All,
Maceij wrote:
[1]
http://lists.w3.org/Archives/Member/member-webapps/2008OctDec/0010.html
[2]
http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0047.html
[3]
http://lists.w3.org/Archives
All,
Maceij wrote:
[1]
http://lists.w3.org/Archives/Member/member-webapps/2008OctDec/0010.html
[2]
http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0047.html
[3]
http://lists.w3.org/Archives/Public/public-webapps/2008JulSep/0186.html
[4]
http://lists.w3.org/Archives/Public/pub
Maciej,
My first question would be:
Why did you ignore Apple's proposal to start with a minimal common
interface (which most people seemed to like) and instead wrote a draft
that is the union of all things in Robin's original spec, all things
that Mozilla happened to implement, and a bunch
The Call for Consensus regarding a new WD of the FileUpload
specification notwithstanding, I think it prudent to *not* publish a WD
till members of the WG get a chance to comment on my editor's draft, and
till the potential F2F at the upcoming TPAC has taken place.
I'd thus like commentary o
Sam,
I don't think we should include synchronous access to File data
provided by:
DOMString getDataAsText(in DOMString encoding) raises(FileException);
DOMString getDataAsBase64()
raises(FileException);
DOMString getDataA
All,
I agree we should first discuss use cases and requirements, before coming up
with APIs.
http://dev.w3.org/2006/webapi/FileUpload/publish/FileUpload.xhtml#requirements
I incorporated suggestions from Garret S, Jonas, and distilled some
things from a few others. I also am comin
Arthur Barstow wrote:
Thanks for taking the lead on this Arun!
Since we eventually need to show we've "satisfied its [=the spec's]
relevant technical requirements" [1], did the Web API WG do some
related requirements work? If yes, where can we find that work?
I think it makes sense to write
All,
On behalf of Mozilla, I'd like to take over as editor of the FileUpload
spec., which was actually once assigned to me quite some time ago :)
Of course, I think that
form.getDataAsString();
form serialization is out of scope of this particular specification, but
I think other things
All,
At the recent F2F discussions in Redmond covering XMLHttpRequest (Level
2) and Access Control, the question of user involvement came up more
than once. This discussion raised issues about whether or not the user
should be informed by a user interface mechanism in the browser that a
cro
Sunava Dutta wrote:
On Jun 25, 2008, at 1:09 PM, Arun Ranganathan wrote:
Mozilla
presents preliminary thought on the subject [1], and notes similar
straw persons proposed by WHATWG [2] and by Google Gears [3]. Also
for reference see worker threads in C# [4]. The Web Apps working
Maciej,
1. Worker Threads in Script.
Apple is interested in a worker API. The key issues for workers, in my
opinion, are security, messaging, and which of the normal APIs are
available. Right now, these things are covered in HTML5, so I think
that may be a better place to add a Worker API
Doug Schepers, Charles McCathieNevile (Chairs), Members of the WG,
On behalf of Mozilla, I'd like to introduce the possibility of two new
work items for this group to consider. Neither of these is presented as
a fait accompli, although we would like to consider both of these for
inclusion in
chaals et al.,
Yep. I am waiting for people to comment on whether they are happy to
roll up about 11 on Tuesday
I am happy enough with an 11a.m. start time; I suspect, however, that
our discussions will run over a bit, and thus, I think we ought to be
prepared for that.
-- A*
301 - 351 of 351 matches
Mail list logo
