Skip to content
This repository has been archived by the owner on May 18, 2022. It is now read-only.

Configuring connectability at runtime #129

Open
daboross opened this issue Jul 18, 2020 · 3 comments
Open

Configuring connectability at runtime #129

daboross opened this issue Jul 18, 2020 · 3 comments
Labels
area: link layer Code Area: BLE Link Layer (establishing and maintaining connections, encryption, etc) status: needs design Needs design work (API, communication between components, etc.) type: enhancement A new feature or an improvement for an existing one

Comments

@daboross
Copy link
Contributor

Hi,

Quick question: would you be open to expanding what LinkLayer can do / what it can choose to do at runtime?

In particular, it currently only advertises Connectable packets, and I'm wondering whether it'd be reasonable to add beacon functionality to it as well.

As I understand it, the current interface is built around choosing a lot of what the device does at compile time - like, one uses Beacon to be a beacon, or LinkLayer to be a connectable device. This seems appropriate for direct usages of rubble, but makes it a bit harder to build good wrappers around all of the functionality, like what I'm doing to use it in TockOS. I'd ideally like to be able to use the same data structures for all kinds of functionality (connectable device, beacon, scanner for other devices). So - would you be alright with duplicating some of the functionality, for the sake of making LinkLayer give access to rubble's full functionality?

This could also make it easier to use or to adapt examples to different use cases. Not sure if that's worth the extra complexity, though.

@jonas-schievink
Copy link
Owner

Hmm, this is a fair point. Would it be possible to switch between Beacon and LinkLayer in Tock by putting both into an enum? I'd be happy with adding functionality that helps with that, but making LinkLayer do everything does not immediately seem like the right thing here (though maybe it would be good to have a separate layer around that, essentially putting the enum in Rubble itself).

@daboross
Copy link
Contributor Author

My apologies for not getting back on this earlier! That sounds like it should work, and switching between the two with an enum should be reasonable.

but making LinkLayer do everything does not immediately seem like the right thing here

I think too caught up in my particular use case, and missed the larger picture - this makes sense.

(though maybe it would be good to have a separate layer around that, essentially putting the enum in Rubble itself)

Since I'll be building this anyways, how about I go ahead and make a PR when it's done? And if it ends up not being particularly useful, then it can always live in my integration code instead.

@jonas-schievink
Copy link
Owner

Sounds good!

@jonas-schievink jonas-schievink added area: link layer Code Area: BLE Link Layer (establishing and maintaining connections, encryption, etc) type: enhancement A new feature or an improvement for an existing one status: needs design Needs design work (API, communication between components, etc.) labels Aug 5, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area: link layer Code Area: BLE Link Layer (establishing and maintaining connections, encryption, etc) status: needs design Needs design work (API, communication between components, etc.) type: enhancement A new feature or an improvement for an existing one
Projects
None yet
Development

No branches or pull requests

2 participants