On Aug 19, 2009, at 1:28 PM, Arun Ranganathan wrote:
Nikunj R. Mehta wrote:
Hi Arun,
Thanks for pulling together all those references and sharing your
research conclusions in such painstaking details. I really
appreciate your hard work. I was particularly interested in seeing
whether yo
Nikunj R. Mehta wrote:
Hi Arun,
Thanks for pulling together all those references and sharing your
research conclusions in such painstaking details. I really appreciate
your hard work. I was particularly interested in seeing whether you
had included the Java I/O API design in your work. Eviden
Hi Arun,
Thanks for pulling together all those references and sharing your
research conclusions in such painstaking details. I really appreciate
your hard work. I was particularly interested in seeing whether you
had included the Java I/O API design in your work. Evidently, you did,
but i
Hi Jonas,
I am afraid that this proposal doesn't actually improve upon the
editor's draft in a meaningful way.
There are concepts here that are completely unrelated to file access
such as status and readyState. There seems to be little to no benefit
in introducing attributes just so that
On Mon, 17 Aug 2009 16:07:48 +0200, Arun Ranganathan wrote:
> I'm willing to change the specification to support Events and Readers,
> though I don't necessarily think it is "more JavaScripty." I continue
> to be concerned that we've made the model a bit more complex, but it
> certainly is
Nikunj,
While the above API does have the advantages that we agree come with
a model that stems from EventTarget and events, I'm concerned that
we've complicated the API for an edge case. I *do* agree that
progress events are desirable, especially given leaky abstractions
for file systems
Please don't snip the context. If I say something in the context of
what someone else was stating, the context is important for discussion.
On Aug 18, 2009, at 2:39 PM, Olli Pettay wrote:
On 8/18/09 11:08 PM, Nikunj R. Mehta wrote:
Do we need asynchronous APIs if files are local and file syst
On 8/18/09 11:08 PM, Nikunj R. Mehta wrote:
Do we need asynchronous APIs if files are local and file system access
is fast?
Files that you select from file system aren't necessarily local and
the system access can be very slow in some cases.
I use sshfs all the time to mount remote systems to lo
On Aug 12, 2009, at 6:32 AM, Arun Ranganathan wrote:
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 DOMS
On Tue, Aug 18, 2009 at 11:04 AM, Arun Ranganathan wrote:
> Aaron Boodman wrote:
>>
>> On Mon, Aug 17, 2009 at 2:45 AM, Olli Pettay
>> wrote:
>>
>>>
>>> On 8/17/09 12:33 AM, Michael Nordman wrote:
>>>
Strictly speaking, I think the seperate 'Reader' class makes for a more
correct API
Aaron Boodman wrote:
On Mon, Aug 17, 2009 at 2:45 AM, Olli Pettay wrote:
On 8/17/09 12:33 AM, Michael Nordman wrote:
Strictly speaking, I think the seperate 'Reader' class makes for a more
correct API. The two corners above would not conflict since each would
presumably be working with
On Mon, Aug 17, 2009 at 2:45 AM, Olli Pettay wrote:
> On 8/17/09 12:33 AM, Michael Nordman wrote:
>>
>> Strictly speaking, I think the seperate 'Reader' class makes for a more
>> correct API. The two corners above would not conflict since each would
>> presumably be working with a distinct FileRead
On Mon, Aug 17, 2009 at 2:45 AM, Olli Pettay wrote:
> I'd do
> var reader = new DataReader(someDataObject, DataReader.BINARY);
> reader.onload =
> function(evt) {
> // grab the data using evt.target.getData();
> };
> reader.read();
What's the advantage of this API over what I proposed? Seems
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
On 8/17/09 12:33 AM, Michael Nordman wrote:
Strictly speaking, I think the seperate 'Reader' class makes for a more
correct API. The two corners above would not conflict since each would
presumably be working with a distinct FileReader object. And the
seperate 'Reader' with event handlers seems m
(posting order moved to the bottom).
On Sun, Aug 16, 2009 at 2:33 PM, Michael Nordman wrote:
> On Sat, Aug 15, 2009 at 9:19 AM, Garrett Smith
> wrote:
>>
>> On Tue, Aug 11, 2009 at 7:20 PM, Jonas Sicking wrote:
>> > Here is an alternative proposal for an API for reading files:
>> >
>>
>> [snip p
On Sat, Aug 15, 2009 at 9:19 AM, Garrett Smith wrote:
> On Tue, Aug 11, 2009 at 7:20 PM, Jonas Sicking wrote:
>> Here is an alternative proposal for an API for reading files:
>>
>
> [snip proposal]
>
>>
>> As stated, I'm not convinced that this is a better solution than what
>> the spec currently d
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 webapp issuing
reads against
On Tue, Aug 11, 2009 at 7:20 PM, Jonas Sicking wrote:
> Here is an alternative proposal for an API for reading files:
>
[snip proposal]
>
> As stated, I'm not convinced that this is a better solution than what
> the spec currently does. The only advantage I can see is that it
> supports progress
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();
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();
const unsigned short IN
21 matches
Mail list logo
