Re: Concerns about DOMRequest

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 also agree (as many of my colleagues), and DOMFuture looks good. To
be fair, based on earlier discussions I think the intent was to evolve
DOMRequest to support the same things, but I agree now it is not
there.

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. In addition, we also need
support for scrolling the result set forward and backward with a
sliding buffer with pre-fetch capability.

Then, if a developer made great efforts building e.g. a messaging
conversation view which may be quite complex to make (eventually
assembled from multiple local and remote messaging and contact
databases), then what would make sense is just to keep that model in
sync with the data sources, i.e. instead of making new queries all the
time and transporting most data multiple times over and over again,
just get updates on new, changed, and removed items between versioned
sync events, and preferably only that subset of properties that need
to be displayed in the particular client (DOM). Also, we may want to
update the data sources with data coming from the client. This also
raises the issue of unique identifiers within the system. Also, a
client may want to store a snapshot of such a model into a persistent
cache (for fast start-up, and then re-sync the data). So what we want
is "live" [persistent] models/views with heterogeneous infinite
sources exposed through one or several view-ports with pre-fetch
capability, plus bidirectional data sync with update events and
replayable diffs from versioned sync points for fallback scenarios.
Now that we know what we want, it should be easy to define a good JS
pattern for it ;-).

Someone could say we should design sysapps API's being data storage
agnostic. I would very much agree with this, but in practice already
there are API design choices which hard-code certain optimizations in
the function signatures (assuming a certain implementation). While IMO
this should be avoided whenever possible, I can also see that the DOM
was made for documents and it is not really suitable for data,
therefore various kludges are needed to simulate things working. :-/
There is just no such thing as perfect SW.

Since Web API's too will never be perfect, the only way I see forward
is to enable their evolution with the least possible pain. Such
possibility comes only when you know where you may get in the future,
and also where you can start from (building simple), so it is both a
top-down and bottom-up process. That's exactly what we should do in
sysapps WG (as there is both top-down and bottom-up experience
present), and now it all depends on what blend we can make. Any help
is appreciated.

[1] http://sysapps.github.com/sysapps/proposals/Messaging/Messaging.html#messagingcursor-interface

Best regards,
Zoltan


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 20:51:35 UTC