Re: Streams and Blobs

[Glenn Maynard]

On Fri, Mar 15, 2013 at 7:23 PM, Jonas Sicking  wrote:

> > Specifically, I'd recommend that when readyState isn't UNSENT, setting
> > responseType to "stream" should fail, and if readyState is set to
> "stream"
> > then setting it to something else should fail.  That is, once the
> request is
> > started it's too late to change into or out of stream mode.
>
> That would mean not supporting the ability to choose to handle a
> response as a Stream based on metadata in the response. That was the
> reason we decided to support setting .responseType in the
> HEADERS_RECEIVED state to other values. I don't see why the same
> reasons doesn't apply here.
>

Change "readyState != UNSENT" above to "readyState > HEADERS_RECEIVED".
That means you have a last chance to change to or from stream mode during
the HEADERS_RECEIVED onreadystatechange event, after headers are available
and before any of the body is read, but once you're in LOADING or DONE,
stream mode is locked in (or out).  (This should apply to both of the XHR
models we've been discussing.)

-- 
Glenn Maynard

Re: Streams and Blobs

[Jonas Sicking]

On Fri, Mar 15, 2013 at 2:36 PM, Glenn Maynard  wrote:
>> I guess we could always make the Stream object immediately produce an
>> error if .responseType is changed to something other than "stream".
>
> Specifically, I'd recommend that when readyState isn't UNSENT, setting
> responseType to "stream" should fail, and if readyState is set to "stream"
> then setting it to something else should fail.  That is, once the request is
> started it's too late to change into or out of stream mode.

That would mean not supporting the ability to choose to handle a
response as a Stream based on metadata in the response. That was the
reason we decided to support setting .responseType in the
HEADERS_RECEIVED state to other values. I don't see why the same
reasons doesn't apply here.

/ Jonas

Pointer lock updated with clarification of lock and focus requirements.

[Vincent Scheib]

After discussion with Olli Pettay I have clarified portions of the pointer
lock specification.

https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
https://dvcs.w3.org/hg/pointerlock/diff/6543d83c0b74/index.html

When requesting pointer lock, this paragraph replaces previous statements
regarding the target being in the DOM tree.
"""
Pointer lock must succeed only if the target is in the active document of a
browsing context which is (or has an ancestor browsing context which is) in
focus by a window which is in focus by the operating system's window
manager. The target element and its browsing context need not be in focus.
"""

In Requirements, clarification was added that focus MAY be shifted out of a
document and into others without exiting lock:
"""
The Pointer Lock API must exit the pointer lock state if the target is
removed from its document, or the user agent, window, or tab loses focus.
Moving focus between elements of active documents, including between
browsing contexts, does not exit pointer lock. E.g. using the keyboard to
move focus between contents of frames or iframes will not exit.
"""

Feedback and suggestions welcome.

Re: Streams and Blobs

[Glenn Maynard]

On Fri, Mar 15, 2013 at 5:07 AM, Jonas Sicking  wrote:

> For an async XHR, if .responseType is set to "stream", then when we
> reach the HEADERS_RECEIVED state .response is set to a Stream object.
> (See more about this below)
>
> As data is being downloaded, we add the data to the end of the Stream
> and then fire the normal ProgressEvent events on the XHR object.
> Putting data into the Stream might cause other actions to happen,
> including firing of events. These actions thus happen before the
> ProgressEvent is fired on the XHR object.
>

This isn't guaranteed.  Progress events are queued tasks, and the "other
actions" (such as EventSource's onmessage) are also typically queued
tasks.  Since they're from different task sources, the order the tasks are
performed is unspecified.

For a sync XHR in Workers, if .responseType is set to "stream" when
> XHR.send() is called, we block until the HEADERS_RECEIVED state is
> reached. At that point we return from the .send() function and return
> a newly constructed Stream object. Note that reading from the Stream
> object should likely not be permitted synchronously, even within
> workers. So all that's synchronous here is waiting until we reach the
> HEADERS_RECEIVED state.
>

Synchronous XHR returns when it reaches DONE.  Returning at
HEADERS_RECEIVED would be strange and inconsistent.

Not supporting synchronously reading from streams is also strange.  We
should definitely be able to support this, just like we support other
synchronous I/O in workers.  Even if we don't tackle exposing this right
away, having an API design incapable of supporting it would be a serious
mistake.

This all seems to be bending and twisting XHR, and imposing arbitrary
restrictions, in order to try to make the API work in the way you first
envisioned it.  The approach I've suggested doesn't require these
contortions and restrictions.

I guess we could always make the Stream object immediately produce an
> error if .responseType is changed to something other than "stream".
>

Specifically, I'd recommend that when readyState isn't UNSENT, setting
responseType to "stream" should fail, and if readyState is set to "stream"
then setting it to something else should fail.  That is, once the request
is started it's too late to change into or out of stream mode.

-- 
Glenn Maynard

Re: Streams and Blobs

[Jonas Sicking]

On Mar 15, 2013 5:33 AM, "Anne van Kesteren"  wrote:
>
> On Fri, Mar 15, 2013 at 10:07 AM, Jonas Sicking  wrote:
> > For a sync XHR in Workers, if .responseType is set to "stream" when
> > XHR.send() is called, we block until the HEADERS_RECEIVED state is
> > reached. At that point we return from the .send() function and return
> > a newly constructed Stream object. Note that reading from the Stream
> > object should likely not be permitted synchronously, even within
> > workers. So all that's synchronous here is waiting until we reach the
> > HEADERS_RECEIVED state.
>
> I think this is very weird. XMLHttpRequest governs network transfers.
> If XMLHttpRequest just terminates at that point, something is missing.

It is definitely different, but I don't see any actual problems with it.
I.e. I don't think it'll be hard for authors to understand, nor do I think
it'll lead to subtle bugs.

/ Jonas

Re: [PointerLock] Should there be onpointerlockchange/onpointerlockerror properties defined in the spec

[Vincent Scheib]

I have added onipointerlockchange and onpointerlockerror to the partial
document IDL in the pointer lock specification.

Webkit currently only defines these event handler attributes on document.
Unless a reason is raised to add them elsewhere, I do not plan to add
additional attributes elsewhere, for reasons discussed in fullscreen
specification primarily regarding the confusing when releasing exiting due
to an element being removed from the DOM, and confusion over multiple
listener points.

https://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html
https://dvcs.w3.org/hg/pointerlock/diff/86bc101925d8/index.html



On Thu, Mar 14, 2013 at 12:05 PM, Simon Pieters  wrote:

> On Thu, 10 Jan 2013 18:24:52 +0100, Boris Zbarsky 
> wrote:
>
>  And if so, which objects should they be on?  Window?  Documents?
>>  Elements?
>>
>
> Currently event handlers are available on all of Window, Document and
> HTMLElement even if the relevant event just fires on one of them, so I
> suggest we do that.
>
> --
> Simon Pieters
> Opera Software
>
>

[editing] table manipulation commands

[Shezan Baig]

Hi,

I would like to propose adding some basic table manipulation commands
to the editing spec [1].  Something along the lines of:

execCommand("InsertColumnsBefore", false, numColumns);
execCommand("InsertColumnsAfter", false, numColumns);
execCommand("DeleteSelectedColumns", false);

execCommand("InsertRowsBefore", false, numColumns);
execCommand("InsertRowsAfter", false, numColumns);
execCommand("DeleteSelectedRows", false);

These are common table operations supported by many rich text editors,
but there doesn't seem to be any support for them in browsers.  The
"DeleteSelectedColumns" command seems a bit weird because there's no
way to actually select columns, and support for multi-range selection
seems to be going away [2], but I think for now if it deletes the
column where the caret is currently at, it should be good for now.

Another command I would like to propose is:

execCommand("JustifyColumns", false, "left");
execCommand("JustifyColumns", false, "center");
execCommand("JustifyColumns", false, "right");
execCommand("JustifyColumns", false, "justify");

Note: The JustifyColumns command wouldn't be necessary if we can
instead come up with a reasonable way to select columns.

Thoughts?

Thanks,
Shezan

[1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=753718

WebSocket API - server initiated close

[Zhong Yu]

(sorry if this is a repost, I think my prev message got lost)

Hi,

If a client app connects to a server through WebSocket API, and server
sends a close frame, how is the client app notified? Does the client
stack automatically respond with a close frame, then raise a "close"
event?

Meanwhile, if the client app is invoking send() while the server close
frame arrives, what happens? The paragraph about "bufferedAmount"
implies that send() won't fail, is that correct?

Thanks,
Zhong Yu

CfC: move WebApps' test suites to Github; deadline March 22

[Arthur Barstow]

As you probably know, the HTMLWG recently moved its test suite to GitHub 
(GH). Tobie, Robin, Odin, Ms2ger and others propose WebApps do the same 
and this is a Call for Consensus to do so.


Odin defined the new testing process for GH in [Proposal] and this will 
replace most, if not all, of the testing processes already agreed 
[Testing]. (Some things like using testharness.js will remain the same.)


Assuming this CfC passes:

* [Proposal] will likely be updated as we gain experience with GH and 
may be replaced by more general information like 
.


* The root of the repository will be the same as HTML(WG): 
 and each of WebApps' specs 
will have its own subdir. For example the Web Storage test suite would 
be .


* WebApps' hg test repository  will 
become Read-only (i.e. write access will be turned off).


* Tobie, Robin, Odin and Ms2ger will do the work of the move (Test 
Facilitators are not required to do the work).


If you have any comments or concerns about this CfC, please reply to 
this e-mail by March 22 at the latest. Positive response is preferred 
and encouraged, and silence will be considered as agreement with the 
proposal.


-Thanks, AB

[Proposal] 
[Testing] 

RE: security model of Web Components, etc. - joint work with WebAppSec?

[Hill, Brad]

As I mentioned in my introductory message, I am specifically interested in the 
security model of components loaded cross-origin - do they get complete control 
of the application / DOM into which they are loaded?  Does an application have 
any ability to restrict or explicitly pass capabilities to a cross-origin 
component?

-Brad Hill

> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@nokia.com]
> Sent: Friday, March 15, 2013 7:20 AM
> To: Hill, Brad; Dimitri Glazkov
> Cc: public-webapp...@w3.org; public-webapps
> Subject: Re: security model of Web Components, etc. - joint work with
> WebAppSec?
> 
> On 3/14/13 8:16 PM, ext Charles McCathie Nevile wrote:
> > On Thu, 14 Mar 2013 18:15:14 +0100, Dimitri Glazkov
> >  wrote:
> >
> >> On Thu, Mar 14, 2013 at 7:10 AM, Hill, Brad 
> >> wrote:
> >>
> >>> Is there time available on the April F2F agenda for discussion of this?
> >>> If not in WebApps, would relevant WG members be willing to join us
> >>> if we found time to discuss in WebAppSec's timeslot Thursday or
> >>> Friday?
> >>>
> >> http://www.w3.org/wiki/Webapps/April2013Meeting#Potential_Topics
> >> Shows agenda wide open so far. Should we just plop something into one
> >> of the slots?
> >
> > Yep, that's a reasonable thing to do...
> 
> I allocated a slot for the joint meeting on Thursday from 2:30-3:00. If anyone
> thinks more time is needed, please speak up.
> 
> Please use public-webapps@w3.org for _all_ Web Components discussions and
> I encourage feedback, comments, etc. in _advance_ of the meeting.
> 
> FYI Brad, Dimitri and the Editors have created a suite of Web Components
> specs. The set of specs that have already been published is:
> 
> * Web Components Introduction
> 
> 
> * HTML Templates
>  file/tip/spec/templates/index.html>
> 
> * Shadow DOM
> 
> 
> There is at least one unpublished ED (not sure if this is ready yet for 
> security
> review):
> 
> * Web Components ( and Components API)
>  file/tip/spec/components/index.html>
> 
> Dimitri - if you can think of specific areas of potential security concerns 
> you
> would like reviewed or if I missed any specs, please let us know.
> 
> -Thanks, ArtB
> 
> 
> >
> > cheers
> >
> > Chaals
> >

[webcomponents] linking using ?

[Mike Kamermans]

Hey all,

I searched the archive at
http://lists.w3.org/Archives/Public/public-webapps/ and checked out
the 
https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html#definitions
and https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html
specs, but couldn't find anything about this in them:

are there provisions in the spec (or is it in the works) to add a new
link type so that if some person A defines a stack of useful
templates, and person B wants to use those templates, they can include
them on their own page using http://personA/templates.html";> (or rel="components", or some
other relation name that makes sense for the role the link plays)?  I
was thinking about this in terms of using web components for something
like Mozilla's Popcorn Maker, where it would be really cool if we
could define all our components as templates, and then tell everyone
"this is our collection of templates, go grab
popcorn.webmaker.org/templates.html if you want to use these on your
own pages!". I really love the idea of web components, but it feels
like being able to share them in the same way you can share .js or
..css files would make them ridiculously powerful on the future web =)

- Mike "Pomax" Kamermans
Mozilla Foundation

[FileAPI]

[Michaël Rouges]

Hello,

I have a few suggestions (for Blob URL) for you, because in my experience, they
should be part of the specification.


*The events:*

Currently it is not possible not to know if a Blob URL has been loaded by
the browser, whether it is an image, a file download, etc..

For example, currently, I am developing a text editor allowing my users to
save their changes, using an anchor.

No method allows me to notify the user that the file has been saved (by
changing the color of the editor tab, for example, like Notepad++).

In addition, these events could be useful to ensure that the Blob URL is
loaded only once.


*The name of the file:*

A file name may likewise be very useful. I think a consideration of option
as BlobURL.name and/or based on the value of the download attribute of an
anchor to which the Blob URL is attached.


*The full path of the file:*

Currently, according to my tests on Firefox, I noticed the inability to
specify the full path of the file, converts all Firefox ":" & "/" by
underscores.

I am not suggesting that when the user clicks, the file is saved to the
specified path directly but offers a prompt browser to save the file to the
specified path, just like a Save as.

In my opinion, the full path chosen by the user should be able to be recovered,
for example, for monitoring the integrity of the application.

It should be specified, either by the download attribute value or by a Blob URL
property.



Well, that's all for now, if you have any questions, do not hesitate to
contact me, I will answer with pleasure.

Cordially,

Michaël Rouges

WebSocket API - server initiated close

[Zhong Yu]

Hi,

If a client app connects to a server through WebSocket API, and server
sends a close frame, how is the client app notified? Does the client
stack automatically respond with a close frame, then raise a "close"
event?

Meanwhile, if the client app is invoking send() while the server close
frame arrives, what happens? The paragraph about "bufferedAmount"
implies that send() won't fail, is that correct?

Thanks,
Zhong Yu

Re: Streams and Blobs

[Anne van Kesteren]

On Fri, Mar 15, 2013 at 10:07 AM, Jonas Sicking  wrote:
> For a sync XHR in Workers, if .responseType is set to "stream" when
> XHR.send() is called, we block until the HEADERS_RECEIVED state is
> reached. At that point we return from the .send() function and return
> a newly constructed Stream object. Note that reading from the Stream
> object should likely not be permitted synchronously, even within
> workers. So all that's synchronous here is waiting until we reach the
> HEADERS_RECEIVED state.

I think this is very weird. XMLHttpRequest governs network transfers.
If XMLHttpRequest just terminates at that point, something is missing.


-- 
http://annevankesteren.nl/

Re: security model of Web Components, etc. - joint work with WebAppSec?

[Arthur Barstow]

On 3/14/13 8:16 PM, ext Charles McCathie Nevile wrote:
On Thu, 14 Mar 2013 18:15:14 +0100, Dimitri Glazkov 
 wrote:


On Thu, Mar 14, 2013 at 7:10 AM, Hill, Brad  
wrote:



Is there time available on the April F2F agenda for discussion of this?
If not in WebApps, would relevant WG members be willing to join us 
if we

found time to discuss in WebAppSec’s timeslot Thursday or Friday?


http://www.w3.org/wiki/Webapps/April2013Meeting#Potential_Topics Shows
agenda wide open so far. Should we just plop something into one of the
slots?


Yep, that's a reasonable thing to do...


I allocated a slot for the joint meeting on Thursday from 2:30-3:00. If 
anyone thinks more time is needed, please speak up.


Please use public-webapps@w3.org for _all_ Web Components discussions 
and I encourage feedback, comments, etc. in _advance_ of the meeting.


FYI Brad, Dimitri and the Editors have created a suite of Web Components 
specs. The set of specs that have already been published is:


* Web Components Introduction 



* HTML Templates 



* Shadow DOM 



There is at least one unpublished ED (not sure if this is ready yet for 
security review):


* Web Components ( and Components API) 



Dimitri - if you can think of specific areas of potential security 
concerns you would like reviewed or if I missed any specs, please let us 
know.


-Thanks, ArtB




cheers

Chaals

Re: RfR: Web Workers Test Cases; deadline March 28

[Simon Pieters]

On Thu, 14 Mar 2013 20:34:52 +0100, Arthur Barstow   
wrote:


This is a WG-wide Request for Review [RfR] for the tests Microsoft and  
Opera submitted for the Web Workers CR [CR]:





Simon (Web Workers' `Test Facilitator`) proposed in [1] the tests are  
sufficient to test the CR's exit criteria.


If you have any comments, please send them to  
public-webapps-testsu...@w3.org by March 28.


I've looked at all the files in  
http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/ , below  
are my comments.


http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerGlobalScope_ErrorEvent_message.htm

assert_not_equals(err.message, undefined);
assert_not_equals(err.message.indexOf(ErrorMessage), -1);

I think this assertion should be removed. The spec doesn't require any  
particular text in the message argument of onerror, so it doesn't make  
sense to check the value in a test, beyond checking that it is a string.  
I'd suggest the following assertion instead of the two above:


assert_equals(typeof err.message, 'string');

(Same thing in Worker_ErrorEvent_message.htm.)

The WorkerGlobalScope_ErrorEvent tests are not testing ErrorEvent at all,  
but are testing WorkerGlobalScope#onerror and its arguments. I suggest  
renaming these tests and their description to be less confusing as to what  
they are testing.


http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerGlobalScope_EventTarget.htm

 WorkerGlobalScope implements EventTarget 
var t = async_test("Test Description: WorkerGlobalScope implements  
EventTarget");


This doesn't affect what the test does, but in the spec the interface  
inherits from EventTarget, rather than implements it.


assert_regexp_match(target, /\[object (.*?)Worker(.+?)\]/);

This should be instead:

assert_equals(target, '[object WorkerGlobalScope]');

http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerGlobalScope_removeEventListener.htm

This has trailing junk that should be removed.

This test also appears to be brittle as to whether it produces a result (I  
often get Not Run result). It appears to have to do with timing -- it sets  
a setTimeout that may or may not be longer than the timeout set in  
setup(). Other tests use the same pattern. I would recommend having a  
fixed number in setTimeout of, say, 100ms, and do this for all tests that  
contain `time * 2`. (Some tests do this already.)


setTimeout(t.step_func(VerifyResult), time * 2);

change to

setTimeout(t.step_func(VerifyResult), 100);

That appears to give more stable results for me. I also recommend changing  
the timeout in setup() in all tests to 2000ms since it might take some  
time to load the worker file, and I seem to get Not Run sometimes (when  
loading a test the first time) for some tests even if they're just waiting  
for a message event.


http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerLocation_hash_nonexist.htm

var t = async_test("Test Description: WorkerLocation hash attribute  
returns an empty string when there is no  component in input  
URL.");


change to

var t = async_test("Test Description: WorkerLocation hash attribute  
returns an empty string when there is no  component in input URL.");


(Similarly in other files, search for `<`.)

worker.postMessage(EvalScript);

EvalScript is not defined. I think the whole line can be removed. (Same  
error in some other files.)


http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/WorkerNavigator_appName.htm

var description = "WorkerNavigator appName: Returns the name of the  
browser: " + window.navigator.appName;


Remove window.navigator.appName from the description since it complicates  
comparing results of tests between browsers if the names of the tests  
differ between browsers. (Similarly for the other WorkerNavigator tests.)  
Test names should be fixed strings.


The spec now has a 'language' member for WorkerNavigator but there's no  
test for it.


There are some tests (e.g. the ErrorEvent tests) that are almost  
identical, connect to the same worker, get the same data, and only differ  
in what they check. This seems to be an inefficient way of doing things  
and makes the test suite take longer than necessary to run. I would  
recommend folding such tests together into one file and have separate  
test_async() objects for each thing that is to be tested.


http://w3c-test.org/webapps/Workers/tests/submissions/Microsoft/Worker_ErrorEvent_type.htm

All the Worker_ErrorEvent tests are wrong in that the ErrorEvent.js file  
catches the runtime error in onerror and then returns true, which means  
that the error is "handled", and no error event should be fired on the  
worker object (in the window context). The worker shou

Re: Streams and Blobs

[Jonas Sicking]

After pondering this over for a few days, here's what I propose.

For an async XHR, if .responseType is set to "stream", then when we
reach the HEADERS_RECEIVED state .response is set to a Stream object.
(See more about this below)

As data is being downloaded, we add the data to the end of the Stream
and then fire the normal ProgressEvent events on the XHR object.
Putting data into the Stream might cause other actions to happen,
including firing of events. These actions thus happen before the
ProgressEvent is fired on the XHR object.

For a sync XHR in Workers, if .responseType is set to "stream" when
XHR.send() is called, we block until the HEADERS_RECEIVED state is
reached. At that point we return from the .send() function and return
a newly constructed Stream object. Note that reading from the Stream
object should likely not be permitted synchronously, even within
workers. So all that's synchronous here is waiting until we reach the
HEADERS_RECEIVED state.

There is an additional issue that needs to be resolved however. What
does the following code do?

var xhr = new XMLHttpRequest();
xhr.open("GET", url);
xhr.send();
xhr.onreadystatechange = function(e) {
  if (xhr.readyState != xhr.HEADERS_RECEIVED) {
return;
  }
  xhr.response === ""; // true
  xhr.responseType = "stream";
  xhr.response instanceof Stream; // true or false?
  xhr.responseType = "text";
  xhr.response === ""; // true or false?
}

We normally allow setting .responseType during the readystatechange
handler for the HEADERS_RECEIVED state transition. But it seems silly
if you have to wait for the event handler to exit before you can get
at the Stream object. But it also seems weird that xhr.response would
synchronously change into a Stream object when .responseType is set to
"stream".

Granted, we do currently synchronously change .response from empty
string to null when .responseType is set to something other than "" or
"text". But it seems weird to allow setting .responseType to "stream",
grabbing the Stream object, and then setting .responseType to
something else.

I guess we could always make the Stream object immediately produce an
error if .responseType is changed to something other than "stream".

As far as I can tell this problem exists in all solutions for using
streams that have been discussed so far. I.e. it's not specific to any
properties of the above proposal.

/ Jonas

Re: IndexedDB, what were the issues? How do we stop it from happening again?

[Tobie Langel]

On Friday, March 15, 2013 at 4:11 AM, Jarred Nicholls wrote:
> On Thu, Mar 14, 2013 at 10:19 PM, Alex Russell  (mailto:slightly...@google.com)> wrote:
> > > On Thu, Mar 14, 2013 at 6:36 PM, Glenn Maynard  wrote:
> > 
> 
> 
> > > Workers exist
> > > explicitly to allow you to do expensive synchronous stuff without
> > > janking the main thread. (Often, the expensive synchronous stuff will
> > > just be a bunch of calculations, so you don't have to explicitly break
> > > it up into setTimeout-able chunks.)
> > > 
> > > The entire reason for most async (all?) APIs is thus irrelevant in a
> > > Worker, and it may be a good idea to provide sync versions, or do
> > > something else that negates the annoyance of dealing with async code.
> > 
> > My *first* approach to this annoyance would be to start adding some async 
> > primitives to the platform that don't suck so hard; e.g., Futures/Promises.
> 
> +1. Libraries cover that fairly well; albeit I think we all would enjoy such 
> things to be first-class citizens of the platform. I've seen some good 
> looking implementations and some decent control flow libraries. I use 
> https://github.com/caolan/async a lot in node projects. 
> 
> > Saying that you should do something does not imply that doubling up on API 
> > surface area for a corner-case is the right solution.
> 
> I agree. It may have seemed like a good and simple idea at first - well 
> intentioned for sure - but upon reflection we have to admit it's sloppy, a 
> greater surface area to maintain, and the antithesis of DRY. It's not what I 
> personally would expect from a modern, quality JS api, and I'm probably not 
> the only web dev to share that feeling. At the risk of making a blanketed 
> statement using anecdotal evidence, I would claim that overindulgence from 
> modern libraries in existence today has raised the expectations of web devs 
> in how the web platform architects new apis.

Node.js comes with sync and async APIs (for good reasons) and I haven't heard 
anyone complain that this wasn't DRY.

--tobie