W3C home > Mailing lists > Public > public-rdf-comments@w3.org > April 2013

Re: Futures

From: Dave Longley <dlongley@digitalbazaar.com>
Date: Wed, 17 Apr 2013 17:51:06 -0400
Message-ID: <516F194A.5000600@digitalbazaar.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: public-rdf-comments <public-rdf-comments@w3.org>
On 04/17/2013 11:45 AM, Tab Atkins Jr. wrote:
> On Wed, Apr 17, 2013 at 7:24 AM, Norbert Lindenberg
> <w3@norbertlindenberg.com> wrote:
>> On Apr 16, 2013, at 16:55 , Tab Atkins Jr. wrote:
>>
>>> On Tue, Apr 16, 2013 at 8:30 AM, Markus Lanthaler
>>> <markus.lanthaler@gmx.net> wrote:
>>>> After a short discussion with Robin we decided to use method overloading to
>>>> We also considered Futures but decided that introducing a normative
>>>> dependency to the DOM spec is not acceptable at this stage.
>>> In this case, your API is a textbook example of Futures.  You have an
>>> async call which returns a single value, or an error.  You can't get
>>> much more perfect than that.
>> Maybe Futures should be in a separate spec? They don't seem to have any dependencies on DOM, and having them separate would reduce the bureaucratic hurdles for non-DOM specs to refer to them. Maybe eventually they could migrate into the ECMAScript standard library (currently known as ES chapter 15).
> I suspect that baking them into JS would be a great final destination.
>   In the meantime, though, that doesn't help the stated bureaucratic
> hurdles, because a separate "Futures" spec will be exactly as
> standards-track-advanced as the current DOM spec.
>
> ~TJ
>

I think the API for Futures looks pretty nice. I do have a few concerns 
about using Futures with the JSON-LD API, however.

1. Browsers haven't implemented Futures yet. This means that JSON-LD API 
implementors now have to implement Futures themselves or link to a 
dependency that does so for them. This is unfortunate overhead, but it 
could be overlooked if Futures really are the future. But are they?

2. JSON-LD API implementations in JavaScript are likely to be used both 
on the client and the server (node.js). Futures are currently tied to a 
DOM spec which, as others have stated, seems unusual. This may make 
Futures seem like a client-side-only feature. Users of a JSON-LD library 
may feel forced to create a more convenient or conventional wrapper on 
the server-side. JSON-LD libraries that work both in the client and in 
node.js may expose an alternative API server-side to get better module 
adoption or to reduce time spent doing support. Users of libraries that 
provide two APIs may either avoid the Futures API on the client -- or 
write yet another wrapper around the Futures API to ensure that native 
support gets used when available. It seems to me that Futures really 
need to be integral to the language or become more popular and a 
well-understood alternative to the node.js continuation-passing callback 
style.

3. While WebIDL is a language for describing APIs meant to be 
implemented by browsers, we also expect the JSON-LD API (or something 
very close to it) to be implemented in various languages (eg: PHP, Ruby, 
Python). If we include Futures, these implementations would become more 
complex and their APIs may appear more foreign in certain environments. 
Implementors may avoid these undesirable effects and APIs will then 
deviate. I don't think this is necessarily that big of a deal, but it is 
an unintended consequence of making Futures first-class values in the 
browser ... as they won't be elsewhere.

So what if Futures aren't chosen to be integrated into ES7 (or whatever 
the numbering scheme is these days)? What if another choice is made? 
Here are some possible outcomes, as I see it:

1. Futures eventually become a part of JavaScript. If JSON-LD uses 
Futures, this is great. If JSON-LD doesn't, then JSON-LD libraries are 
in the same boat as every other library that has an API that works both 
server and client side (presumably, there will be a plan for moving over 
to Futures in node.js should this happen). A new JSON-LD API spec/note 
could be put out that describes the API using Futures.

2. Futures don't become a part of JavaScript -- and no alternative is 
chosen. If JSON-LD uses Futures, then users of implementations will 
likely write wrappers that end up making the JSON-LD API use the 
conventional node.js continuation-passing callback style. JSON-LD 
libraries may either expose two different APIs or link to the person who 
writes the wrapper that makes the module familiar to node.js users. In 
other words, the node.js callback style will be used by anyone sharing 
code between the client or server -- or just anyone used to writing 
node.js code who isn't interested in switching styles for a special 
case. If JSON-LD doesn't use Futures, and Futures do not become popular, 
there's little to no harm done. If Futures do become very popular, it's 
not very different from #1.

3. Futures don't become a part of JavaScript -- and a different 
Promise/Futures API is chosen. Here all of the confusion/overhead from 
#2 happens, plus Futures are scrapped. The upside is that if everything 
from #2 happens, it may be less painful to replace the underlying 
Futures API because people were avoiding it to begin with.

One of the reasons Futures were created was to standardize asynchronous 
APIs (this isn't a problem for node.js, but it is for client-side APIs). 
It seems to me that, until Futures (or any alternative) seem as though 
they will be integrated into JavaScript, that a better way to 
standardize would be to choose the path that has already had great 
success with node.js. That doesn't mean that there aren't other reasons 
to consider Futures -- it just means that another mechanism has a proven 
track record. Furthermore, Futures and various other competing 
asynchronous code-flow organizing APIs can easily work on top of the 
style node.js has chosen.

Another reason for choosing Futures over an alternative is that they are 
powerful or technologically superior. This is true when comparing them 
to the simplistic node.js callback style, but I think it's more murky 
when comparing them to other various async code-flow libraries out there 
-- especially considering that Promise-based libraries have been around 
for a while and are not winning the competition.

To reiterate, I do like the way Futures look -- I'm just concerned that 
maybe they won't actually be the winner. If they aren't the winner, then 
a JSON-LD API that uses Futures is a loser. If they do win, then a 
JSON-LD library isn't in a different position from the myriad node.js 
modules that run both on the client and the server. There will be a 
migration plan (if necessary) to deal with that.

Currently, Promises/Futures haven't gained much steam, relatively 
speaking, in the node.js community (where decent async code flow is 
vital). Understanding why that is would be very helpful, but may be too 
difficult to do, especially given the time constraints. If developers 
would actually prefer to use Promises/Futures over the other choices, 
but they feel that they can't due to convention or compatibility, that's 
one thing. However, if they just find the other choices easier to use -- 
or if it's all just personal preference and there's no real consensus -- 
I don't think Futures have that strong of an argument.

-Dave

-- 
Dave Longley
CTO
Digital Bazaar, Inc.
Received on Wednesday, 17 April 2013 21:50:13 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:59:32 UTC