Re: Hybrid promises

Noble is just callbacks and event emitters.  A neat side effect is that my
shim only gets called if you run your code through webpack or browserify
and I don't actually need node's promise implementation.  Anywhere that
navigator.bluetooth exists it's pretty safe to assume a native Promise will
be available :)



On Thu, Sep 24, 2015 at 9:38 AM, Rob Moran <Rob.Moran@arm.com> wrote:

>
> Hey that's cool!
>
> The library I've been working on to abstract the different JS BLE
> implementations is here:
>
> https://github.com/thegecko/bleat
> <https://github.com/thegecko/bleat>
> thegecko/bleat · GitHub
> bleat - Abstraction library for hiding differences in JavaScript BLE APIs
> Read more... <https://github.com/thegecko/bleat>
>
>
>
> I'm just starting to web-bluetooth-ify it [image: 😊]
>
> I wasn't aware of promises in node, that will make things much easier!
>
> Kind regards,
>
> Rob
>
> ------------------------------
> *From:* Jeffrey Yasskin <jyasskin@google.com>
> *Sent:* 24 September 2015 16:30
> *To:* Rob Moran
> *Cc:* public-web-bluetooth@w3.org; monteslu@gmail.com
> *Subject:* Re: Hybrid promises
>
> Note that Luiz Montes is working on an implementation of the noble API in
> terms of Web Bluetooth:
> https://plus.google.com/+LuisMontes/posts/4BJ8zWdagTR. If node apps
> prefer that API because it matches existing Node code better, I think it's
> fine for them to use it.
>
> Node also has native Promises since the 4.0 merge.
>
> I don't mean to scare people off from API feedback in general. We'll
> strongly consider any "this change would make this concrete use case work
> better" feedback, especially if it comes with example code proving the
> point. It's just that the Promise switch is bigger than this one API.
>
> Thanks,
> Jeffrey
>
> On Thu, Sep 24, 2015 at 2:53 AM, Rob Moran <Rob.Moran@arm.com> wrote:
>
>> Thanks, Jeffrey
>>
>> Wrapping the interface to remove the promises as you suggest will work
>> from a developer style perspective, but the underlying implementation would
>> still need to return promises.
>> A wrapper would also change the interface reducing the portability of
>> code between implementations.
>>
>> For example, implementing a web-bluetooth API in node would require a
>> dependency on a promise library (such as es6-promise) even if the api is
>> later wrapped and the promises not used.
>>
>> I'll repost my question on the other list, but as the API is targeted for
>> the web I can see how this is unlikely to change.
>>
>> Kind regards,
>>
>> Rob
>>
>> ________________________________________
>> From: Jeffrey Yasskin <jyasskin@google.com>
>> Sent: 23 September 2015 18:28
>> To: Rob Moran
>> Cc: public-web-bluetooth@w3.org
>> Subject: Re: Hybrid promises
>>
>> This may be more of a question for public-script-coord@w3.org, who
>> govern the style of new web APIs. My understanding is that every new
>> API is using Promises, and folks who want to adapt them back to
>> callbacks can wrap them, just like folks who want to use Promises with
>> old callback-based APIs have to wrap them.
>>
>> https://github.com/hybridables/promise2thunk looks close to what you
>> want, but it works on the output of the function instead of
>> transforming the function itself. Would a similar wrapping library do
>> what you want?
>>
>> We haven't explicitly considered defining a hybrid API that accepts a
>> callback and returns a promise, but I expect most web API experts will
>> oppose that direction, since the web platform will have to keep
>> supporting it even after everyone's switched to promises.
>>
>> Jeffrey
>>
>> On Wed, Sep 23, 2015 at 10:04 AM, Rob Moran <Rob.Moran@arm.com> wrote:
>> > Hi group,
>> >
>> >
>> > we've been following the web-bluetooth specification closely with
>> interest
>> > and with a view to implementing it as an abstraction interface over
>> other
>> > popular JavaScript-BLE implementations on web, server and mobile.
>> >
>> >
>> > We are aware this is a web-bluetooth specification rather than
>> > JavaScript-bluetooth, however it does rely heavily on the use of ES6
>> > promises, a paradigm not commonly used on many platforms (yet!).
>> >
>> >
>> > Promises are an elegant approach to asynchronous programming, but even
>> in
>> > web development the use of promises could perhaps be considered a
>> choice of
>> > the developer and not forced by the API.
>> >
>> >
>> > We were wondering if a hybrid approach was considered when defining the
>> > specification which allows the choice of using promises (if available)
>> or a
>> > callback with an error object.
>> >
>> >
>> > Examples of this approach can be seen in these npm modules:
>> >
>> >
>> > https://www.npmjs.com/package/hybridify
>> >
>> > https://www.npmjs.com/package/handle-callback
>> >
>> >
>> > Forgive my ignorance if discussions around this are already public.
>> >
>> >
>> >
>> > Kind regards,
>> >
>> >
>> > Rob
>> >
>> >
>> >
>> > ________________________________
>> >
>> > -- IMPORTANT NOTICE: The contents of this email and any attachments are
>> > confidential and may also be privileged. If you are not the intended
>> > recipient, please notify the sender immediately and do not disclose the
>> > contents to any other person, use it for any purpose, or store or copy
>> the
>> > information in any medium. Thank you.
>>
>>
>> ________________________________
>>
>> -- IMPORTANT NOTICE: The contents of this email and any attachments are
>> confidential and may also be privileged. If you are not the intended
>> recipient, please notify the sender immediately and do not disclose the
>> contents to any other person, use it for any purpose, or store or copy the
>> information in any medium. Thank you.
>>
>>
>
> ------------------------------
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>