Re: Concerns about DOMRequest

Le 13/02/2013 21:51, Kis, Zoltan a écrit :
> Then, we'd also need best methods for handling async requests which
> return a stream of data, like transient contact list, so that data is
> started to be pushed as soon as available/buffered, before the query
> ended. Currently this can be done with a DOMRequest where the 'result'
> attribute is set to an iterator, which itself handles fetching the
> next chunk asynchronously by reusing the DOMRequest itself. [1]
> I think this could be done better too.
For streams, I could only advise to follow what Node.js has been doing, 
especially their work on Stream 2 [1] and particularly the recent 
objectMode [2] (stream of objects). If that was just me, I would 
probably standardize their API directly (but I'm not even part of 
sysapps :-p). They've had a huge share of user testing with the first 
API, figured out the issues and came up with a better, more consistent API.
I don't think it'd be possible to reach something as good in a short 
period of time starting a new Stream API from scratch.

David

[1] http://blog.nodejs.org/2012/12/21/streams2/
[2] 
http://nodejs.org/docs/v0.9.8/api/stream.html#stream_new_stream_readable_options

>
>
> On Wed, Feb 13, 2013 at 9:17 PM, David Bruant <bruant.d@gmail.com> wrote:
>> I don't have much to say except that I agree.
>> I've worked 8 months on a medium size Node.js application using the Q
>> library (promises) intensively and DOMRequest are nowhere near promises when
>> it comes to "developer-friendliness" and "code readability" since these are
>> the expressed goals.
>> I encourage to compare the readbility of the 2 code snippets [1] comparing
>> how the FileHandle API is with DOMRequest and how it could be with
>> DOMFuture.
>>
>> So, yes, as a JS developer, I'm begging you to drop DOMRequest in favor of
>> DOMFuture (or make it evolve to get to the same benefit that DOMFuture
>> provide. Path to evolution has been described [2]).
>>
>> Thanks,
>>
>> David
>>
>> [1] https://github.com/slightlyoff/DOMFuture/issues/19#issuecomment-13267982
>> [2] https://github.com/slightlyoff/DOMFuture/issues/19#issuecomment-13284949
>>
>> Le 13/02/2013 19:41, Marcos Caceres a écrit :
>>
>>> I noticed that in the System Application Runtime: Execution and Security
>>> Model [1] document there is the following statement:
>>>
>>> "DOMRequest intend to be used instead of those callbacks to make those
>>> APIs more developer-friendly and help code readability."
>>>
>>> I have some reservations about DOMRequest and the claims above (and all
>>> the derivative interfaces defined by the WG, like AlarmRequest, etc).
>>> DOMRequest seems to be at the core of complexity associated with IndexedDB
>>> [2] and suffers from some serious design flaws:
>>>
>>> 1. It confuses events and callbacks by switching one for the other.
>>>
>>> 2. Forces developers to write synchronous code to handle asynchronous
>>> functionality (i.e., it tries to be a promise, but while - as one developer
>>> described it to me - "taking all the fun out of promises"). This is because
>>> any code relying on DOMRequest must be run in a synchronous function call.
>>>
>>> 3. Because of 2, APIs can't be easily run interactively in a JS console -
>>> which makes learning, development, and manual testing tedious. This leads to
>>> developers then having to build libraries on top of the standardised ones to
>>> actually make the API usable.
>>>
>>> 4. Leads to far illegible programming patterns, leading to less legible
>>> code (see [3] as well as the angry comments from [3]).
>>>
>>> I would kindly request that the group only use this pattern, if, and when,
>>> absolutely necessary - or consider better patterns like the one used by XHR,
>>> promises, or the DOMFuture proposal [4] (which will soon be merged into
>>> DOM4). If the APIs need asynchronous execution, then the most appropriate
>>> pattern should be considered on a case-by-case basis, not taken wholesale.
>>>
>>> I'll note that wholesale adoption of patterns was a noticeable issue in
>>> all the WAC APIs (which tried to copy Geolocation without really
>>> understanding what was good/bad about that pattern and when it's actually
>>> appropriate to use it). It would be a shame if this group made the same
>>> mistakes as WAC when it comes to API design by naively adopting DOMRequest
>>> when better solutions exist for particular use cases/APIs.
>>>
>>> [1]
>>> http://jungkees.github.com/sysapps/proposals/Runtime/Overview.html#domrequest-interface
>>> [2] http://lists.w3.org/Archives/Public/www-tag/2013Feb/0003.html
>>> [3] http://www.html5rocks.com/en/tutorials/indexeddb/todo/#toc-step2
>>> [4] https://github.com/slightlyoff/DOMFuture
>>
>>
>> ---------------------------------------------------------------------
>> Intel Finland Oy
>> Registered Address: PL 281, 00181 Helsinki Business Identity Code: 0357606 -
>> 4 Domiciled in Helsinki
>> This e-mail and any attachments may contain confidential material for
>> the sole use of the intended recipient(s). Any review or distribution
>> by others is strictly prohibited. If you are not the intended
>> recipient, please contact the sender and delete all copies.

Received on Wednesday, 13 February 2013 21:50:31 UTC