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

On Sat, Jun 8, 2013 at 12:20 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> 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.
>

Thanks. What is the IPR status of that proposal? It doesn't contain any
grants in the copyright info. Has/will this be formally submitted to the
W3C under W3C IPR terms?


>
>
>
> 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/
>>>
>>
>>
>