headers
Garrett Smith | 1 Jul 2009 01:22
Picon
Gravatar

Re: File API Feedback

On Tue, Jun 30, 2009 at 1:38 AM, Jonas Sicking<jonas <at> sicking.cc> wrote:
> On Mon, Jun 29, 2009 at 11:52 PM, Garrett Smith<dhtmlkitchen <at> 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 all files in "stress" are successfully read
>> 2) upon completion of each file
>>
>> When reading one large file (a movie, for example), how will the
>> program provide notification of progress of the upload?
>
> I think you might be misunderstanding the proposed API.
>
> The API simply allows reading files from the local file system (once
> the user has elected to grant the page access to a file).
>
> The proposed API is *not* for sending files to a server, for example
> in a Picasa-style app.

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.

It is expected that XMLHttpRequest Level 2 will
> provide that functionality. Since XMLHttpRequest will be used, you'll
> have access to the full range of features available in XMLHttpRequest
> Level 2, such as ability to monitor progress, error and success.
>
(Continue reading)

Permalink | Reply | 24 comments |
headers
Jonas Sicking | 1 Jul 2009 01:29
Gravatar

Re: File API Feedback

On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smith<dhtmlkitchen <at> 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 argument for Progress Events was
> illustrated with an example and a comparison. What was confusing?

What is the use case for the API you are proposing? I agree that what
you are proposing allows for a lot of flexibility, but it also results
in an API that is more complex. Thus I think we should stick with the
current API unless you have use cases in mind that only works in the
API you are proposing.

/ Jonas
Permalink | Reply | 22 comments |
headers
Ian Hickson | 1 Jul 2009 01:51
Picon

Re: Web IDL syntax

On Tue, 30 Jun 2009, Robert Sayre wrote:
> On Tue, Jun 30, 2009 at 5:20 PM, Boris Zbarsky<bzbarsky <at> mit.edu> wrote:
> > Cameron McCormack wrote:
> >>
> >>  * Renamed DOMString to string:
> >>    http://dev.w3.org/2006/webapi/WebIDL/#idl-string
> 
> Yeah, I don't see much benefit to this.

I agree; I think this is just going to cause confusion. The specs for 
years have referred to DOMString throughout.

Personally if this stays I'll just put a typedef somewhere to define 
DOMString and not use the native "string" type directly.

--

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Permalink | Reply | 1 comment |
headers
Garrett Smith | 1 Jul 2009 03:13
Picon
Gravatar

Re: File API Feedback

On Tue, Jun 30, 2009 at 4:29 PM, Jonas Sicking<jonas <at> sicking.cc> wrote:
> On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smith<dhtmlkitchen <at> 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 argument for Progress Events was
>> illustrated with an example and a comparison. What was confusing?
>
> What is the use case for the API you are proposing?

The program wants to attach more than one "success" callback at places
in the code. The program wants to attach a "timeout" callback, to
handle cases where the read operation is too slow.

I agree that what
> you are proposing allows for a lot of flexibility, but it also results
> in an API that is more complex.

Hardly. If no new messages (callbacks) are created, the design
separates messaging and behavior.

How is this:-

file.onsuccess = genericSuccess;
file.onerror = genericError;
file.read();

More complicated than:-
(Continue reading)

Permalink | Reply | 21 comments |
headers
Maciej Stachowiak | 1 Jul 2009 03:42
Picon
Favicon

Re: Web IDL syntax


On Jun 30, 2009, at 4:51 PM, Ian Hickson wrote:

> On Tue, 30 Jun 2009, Robert Sayre wrote:
>> On Tue, Jun 30, 2009 at 5:20 PM, Boris Zbarsky<bzbarsky <at> mit.edu>  
>> wrote:
>>> Cameron McCormack wrote:
>>>>
>>>>  * Renamed DOMString to string:
>>>>    http://dev.w3.org/2006/webapi/WebIDL/#idl-string
>>
>> Yeah, I don't see much benefit to this.
>
> I agree; I think this is just going to cause confusion. The specs for
> years have referred to DOMString throughout.
>
> Personally if this stays I'll just put a typedef somewhere to define
> DOMString and not use the native "string" type directly.

WebKit doesn't have the same technical constraints as Mozilla, however  
this change doesn't really seem helpful and it would be annoying to  
have to replace all instances of DOMString in our existing IDL.

Regards,
Maciej
Permalink | Reply | 0 comments |
headers
Cameron McCormack | 1 Jul 2009 04:05
Picon
Gravatar

Re: Web IDL syntax

Cameron McCormack:
> * Renamed DOMString to string:
>   http://dev.w3.org/2006/webapi/WebIDL/#idl-string

Boris Zbarsky:
> I thought there had been at least some mention of this colliding with  
> existing string types in IDLs that are already in use?  I know this will  
> make it much harder for Mozilla to use webidl IDL fragments "as is"...

Yes, but then Jonas replied saying that Mozilla wasn’t intending on
using them as is.  But if you are, …

Ian Hickson:
> I agree; I think this is just going to cause confusion. The specs for 
> years have referred to DOMString throughout.
> 
> Personally if this stays I'll just put a typedef somewhere to define 
> DOMString and not use the native "string" type directly.

All right.  To me, having an intrinsic type called ‘DOMString’ seems
kinda weird.

Maciej Stachowiak:
> WebKit doesn't have the same technical constraints as Mozilla, however  
> this change doesn't really seem helpful and it would be annoying to have 
> to replace all instances of DOMString in our existing IDL.

find . -name \*.idl | xargs perl -i -pe s/\<DOMString\>/string/g

But OK.  By the way, do you use DOMString as an intrinsic type, or do
(Continue reading)

Permalink | Reply | 6 comments |
headers
Boris Zbarsky | 1 Jul 2009 04:15
Picon
Favicon

Re: Web IDL syntax

Cameron McCormack wrote:
> Boris Zbarsky:
>> I thought there had been at least some mention of this colliding with  
>> existing string types in IDLs that are already in use?  I know this will  
>> make it much harder for Mozilla to use webidl IDL fragments "as is"...
> 
> Yes, but then Jonas replied saying that Mozilla wasn’t intending on
> using them as is.  But if you are, …

I don't know that we've made any decisions along these lines...

> I can easily rename the type back to DOMString.  I’d like to know if you
> all think there is any problem in keeping the name as DOMString but
> removing the null from its set of values, and requiring the use of the
> nullable type ‘DOMString?’ to specify a string type that does allow
> null.  Because then it is different from the traditional DOMString as
> defined in DOM Core.

Are we going to rewrite the existing DOM spec idl to the new syntax as 
needed (e.g getElementsByTagNameNS)?

-Boris
Permalink | Reply | 2 comments |
headers
Cameron McCormack | 1 Jul 2009 04:18
Picon
Gravatar

Re: [WebIDL] grammar in ABNF

Hi Marcin.

Marcin Hanclik:
> Could we have the Web IDL grammar in ABNF?
> I think ABNF is quite well adopted on the market.

I think using ABNF would make the grammar harder to read, since ABNF
quoted terminals are case insensitive, and must be written out as %xHH
characters to get case insensitive treatment.

My hope is that writing the grammar out as a simple LL(1) grammar with
no special syntax for repetition or optional symbols will make it easier
for people to write an IDL parser.

> Otherwise, I think we could have more formal description of the
> grammar used in the current Web IDL spec, since it is easy now to
> misunderstand it having the ABNF syntax used in other specs.

Is it really easy to misunderstand?  ABNF syntax is quite complex
compared to the grammar syntax I am using.  The only perhaps non-obvious
parts are that quoted string terminal symbols are case sensitive and
that whitespace is allowed implicitly between every terminal symbol, but
this is explained in the text in #idl-grammar.  If you can suggest some
specific points that need clarification, I will add some more prefatory
text.

Thanks,

Cameron
(Continue reading)

Permalink | Reply | 5 comments |
headers
Cameron McCormack | 1 Jul 2009 04:23
Picon
Gravatar

Re: Web IDL syntax

Boris Zbarsky:
> Are we going to rewrite the existing DOM spec idl to the new syntax as  
> needed (e.g getElementsByTagNameNS)?

I do think somebody needs to do that.  I don’t think it’s sufficient
(even before this syntax change) to just rely on interepreting the OMG
IDL published in DOM Core as Web IDL.  At the least, [PrototypeRoot]
needs to be specified on the Node interface, so that ECMAScript
prototype chains for, say, HTMLAElement are set up appropriately.

I know that Simon Pieters is working on Web DOM Core
http://simon.html5.org/specs/web-dom-core but I am not sure when that
will be done.  It also won’t include everything from DOM 3 Core.

I think it might be useful for someone to just publish versions of
existing DOM specs’ IDL as Web IDL.  I’m willing to help with that.

--

-- 
Cameron McCormack ≝ http://mcc.id.au/
Permalink | Reply | 1 comment |
headers
Jonas Sicking | 1 Jul 2009 04:36
Gravatar

Re: File API Feedback

On Tue, Jun 30, 2009 at 6:13 PM, Garrett Smith<dhtmlkitchen <at> gmail.com> wrote:
> On Tue, Jun 30, 2009 at 4:29 PM, Jonas Sicking<jonas <at> sicking.cc> wrote:
>> On Tue, Jun 30, 2009 at 4:22 PM, Garrett Smith<dhtmlkitchen <at> 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 argument for Progress Events was
>>> illustrated with an example and a comparison. What was confusing?
>>
>> What is the use case for the API you are proposing?
>
> The program wants to attach more than one "success" callback at places
> in the code. The program wants to attach a "timeout" callback, to
> handle cases where the read operation is too slow.

But *why* would someone want to attach more than one success callback?

What do you mean by timeout? That the OS thinks that accessing the
file takes so long that it aborts and returns a failure? Or that the
page thinks it takes too long?

If the former, there is already an error callback which would be
called on timeout. If the latter, that seems like a decision the page
makes and so no event would be involved.

However having a function that allows you to cancel any pending read,
for example if the read takes too long or is for some other reason no
longer relevant, seems like it might be worth perusing.
(Continue reading)

Permalink | Reply | 20 comments |

Gmane