Re: Use of Futures/Promises in CSS Font Face APIs

Here is the IDL for promises:

https://github.com/slightlyoff/Promises/blob/master/Promise.idl

It doesn't look like there's a need for new ECMAScript features.



On Fri, Jun 7, 2013 at 5:00 PM, Glenn Adams <glenn@skynav.com> wrote:

> Thanks. I know what futures/promises are and used them, along with
> continuation passing, in Scheme and Lisp programming many years ago. I have
> nothing against them as a mechanism for supporting asynchronous programming.
>
> But unfortunately, your article doesn't answer the questions I posed, such
> as "which version of ECMAScript will be required to obtain this features?"
> ES5.1 (I think not); ES6 (I also don't think so); ES7 (maybe?).
>
> If this is true, then CSS FontLoad and Events effectively becomes gated by
> ES7 (or later). Since it appears that use of futures/promises actually
> provides ZERO additional functionality to CSS FontLoad et al, this seems
> like a very high price to pay (in terms of schedule and implementation
> uncertainty) to incidentally endorse a useful, but new (future?) feature.
>
> If this is an accurate description of the facts, then I expect that Cox
> will register an objection to a FPWD and subsequent publishing steps that
> relies up Futures/Promises. Cox believes it important to get this
> functionality implemented and published in an expedient manner and that any
> non-trivial delays in schedule caused by use of a future ES7 or later
> feature will be detrimental to this goal.
>
> Regards,
> Glenn
>
>
>
> On Fri, Jun 7, 2013 at 10:40 PM, Brian Kardell <bkardell@gmail.com> wrote:
>
>>
>> On Jun 7, 2013 9:37 AM, "Glenn Adams" <glenn@skynav.com> wrote:
>> >
>> > During today's presentation of an alternative API for CSS FontLoader,
>> reference was made to so-called "Futures" or "Promises". I would like to
>> know:
>> >
>> > (1) what material improvement is afforded to this alternative when
>> compared with the existing (non-Futures) API proposal? that is, what new or
>> different behavior or functionality is offered by using "Futures"?
>> >
>> > (2) where is the formal definition of a Futures API or functionality
>> that would become a normative dependency were the "Futures" version of the
>> FontLoader API adopted?
>> >
>> > (3) what other W3C APIs under active development (or complete) makes
>> use of said "Futures" APIs?
>> >
>> > (4) does the proposed use of Futures create a dependency on a newer
>> version of ECMAScript than is currently assumed by HTML (which is 5.1)?
>> >
>> > (5) what is the expected impact on schedule for reaching a FPWD (or LC)
>> if this alternative "Futures" approach is followed?
>>
>> Some answers here http://infrequently.org/2013/06/sfuturepromiseg/
>>
>
>