Draft API up for discussion

[Wayne Keenan]

Hi,

Please see this wiki page for some initial thoughts, and lets discus it here.

Thanks

Wayne

[Wayne Keenan]

My preference on driving the Bleson API forward for all roles and for a subset of the primary objects which are non-trivial and have a 'large API surface area', is to create further examples in the same kind of 'example-usage driven' style as on the wiki page.

[IanH]

I didn't seem to be able to edit the page - was that intentional?

Do I understand (looking at this and `python-hcipy`) that `xxx.start()` will start a thread where notifications / callbacks are received? 

Cheers
Ian

[Wayne Keenan]

On Tuesday, October 10, 2017 at 7:41:14 PM UTC+1, IanH wrote:

I didn't seem to be able to edit the page - was that intentional?

it was not, please try again.

 

Do I understand (looking at this and `python-hcipy`) that `xxx.start()` will start a thread where notifications / callbacks are received? 

yes.

All the best

Wayne

[Barry Byford]

Hello,

Rather than going with threads would it make more sense to go with asyncio?

I speak from a position of ignorance but it would seem that asyncio is targeted at the kind of thing this library is looking to do.

A bit of searching around has found this BLE scanner that uses asyncio:

https://github.com/frawau/aioblescan

I've done some experiments this evening and it seems to be working well.

Thoughts?

Cheers,

Barry

[IanH]

Does anyone know if threads work on Micropython? One thing I'd like to do with this is write Device-end code in Python on microcontrollers. There's a forum thread at https://forum.micropython.org/viewtopic.php?t=1864 but it wasn't clear what exactly ended up being implemented.

Cheers
Ian

[Wayne Keenan]

I should probably have just said that the start() method is intended to be a non-blocking call so bleason can fit well with other frameworks that a user may wish to use and which impose their own main loop, how it is implemented well...

It may use threads on Linux but I'd be interested in using asyncio in anger, so let do that shall we.

For MicroPython bleson would use the silicon vendor (or alternative, e.g. Apache Mynewt) provided BLE API and the although bleson API would look and feel the same as the Linux (or other) platform would it be implemented using the MicroPython C module API to save space and avoid the need for any (Micro)Python threads.  (I implemented  bluezero on Apache Mynewt this way, https://thebubbleworks.com/bubblepy/)

[Wayne Keenan]

I've just had a brief look at asyncio documentation and read some blogs, as much as I'd like to have a play I'm not 100% convinced it's the way to go for bleson. Some thoughts:

1. There are differences in the library's API and new Python language keywords (added for support of asyncio) between versions 3.4, 3.5 & 3.6, which could complicate things more than necessary.  

2. Using asyncio imposes its usage on the caller for dispatching from its main loop, something I'd prefer to avoid.

3. A single background thread socket listener may provide 'good enough' performance

thoughts?

[IanH]

I did consider asyncio for the bluepy project, but it doesn't really work too well unless your whole program is written in an event-driven style. For a Device, that's OK, because mostly a device is sitting there responding to events as they happen, but it's awkward for a Central because mostly something else is driving the program execution and the BLE I/O is something you just want to happen synchronously.

For platforms where threads are a problem we could imagine offering a run() method as an alternative to start(), which runs on the caller's thread, perhaps with a timeout. So if you wanted to make a Device running on something without threads the main loop would be along the lines of:

while True:
  device.run(0.1)
  // Poll other stuff here

(In other words, we wrap all our event processing in a run() method, and the threaded version just calls that repeatedly in the background. This is essentially what the _socket_poller() method in hcipy is doing at the minute).

Cheers
Ian

[Barry Byford]

I understand the concern about forcing event loops on people using the library.

The experience with my projects is that polling for things like button presses have been very unreliable.

Enabling notify on a characteristic really needs an event loop.

Scanning also can't(?) be done by polling.

asyncio does seem a good direction to go looking forward so I would be interested if you can point me at any of the blogs because I would be interested in what is/has changed.

I am happy to do some experiments with other things.

Cheers,

Barry

[Wayne Keenan]

These were some of the blog posts:

https://hackernoon.com/asyncio-for-the-working-python-developer-5c468e6e2e8e

http://lucumr.pocoo.org/2016/10/30/i-dont-understand-asyncio/

https://www.blog.pythonlibrary.org/2016/07/26/python-3-an-intro-to-asyncio/

[Wayne Keenan]

or a device.update() method called as often as the caller can or would care to.

[Wayne Keenan]

Hi Ian,

Regarding your comment on the wiki on tge Eddystone subclass.

I guess it depends what we include in the bleson bag. The example I gave for a beacon intended to demonstrate 'raw' access a library like bluezero could use, hence the vague reference to a Eddystone helper and the massive amount of duplication of the example above it, sorry for not making it clearer.

I guess it's time the scope of bleson was firmed up.