Re: Concerns about DOMRequest

I knew there was a W3C stream API somewhere, but I couldn't find it 
yesterday. Here it is: http://www.w3.org/TR/2013/WD-streams-api-20130214/
Very different than the Node.js API from what I can see.
Has it been implemented somewhere already?

David

Le 13/02/2013 22:49, David Bruant a écrit :
> 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 Thursday, 14 February 2013 20:46:28 UTC