fxbox/adapters

The API for defining and registering adapters for the Foxbox.

adapters's Issues

Watchers should adapt their watch as getter are added/removed

The AdapterManager should type-check register_channel_watch

Watchers should inform the client if a getter (dis)appears

Handle saving/loading the set of tags

For the moment, tags live only in memory. We should be able to save them to disk. Basically, each id may be associated to a list of strings.

This means adding to manager::AdapterManager methods

pub fn load(&self, path: String) -> Result<(), Error>;
pub fn save(&self, path: String) -> Result<(), Error>;

Then, when we perform the internal calls to add_service, add_getter or add_setter, we should check in the in-memory list to find out if the service/getter/setter has tags waiting for it.

I'm not sure about the error type.

In a followup issue, we'll think about saving tags as they are added/removed, or associating tags to

Optimize selectors by tags

We currently do not attempt to optimize selectors by tags. We should. For this purpose, we need to maintain tables service_by_tag, getter_by_tag, setter_by_tag – and use them.

Introduce a built-in fake adapter

This would be very useful for combining real devices and simulated devices for tests.

As a bonus, we can basically reuse the code already present in tests/ for that.

Optimize selectors by ChannelKind

We do not attempt to optimize selectors by ChannelKind. We should. For this purpose, we would need to maintain tables getter_by_kind and setter_by_kind – and use them.

Optimize selectors by Id

Some selectors search by id. This could be optimized trivially, since we have maps indexed by id.