Create driver traits #155
Merged
Create driver traits #155
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The registration method and the associated type have been moved into their own trait, `driver::Registrator`. The `driver::API` trait is a super trait, so all drivers must also implement this new trait. Having the registration separate allows us to create common sets of devices for hardware types. For instance, we can make a `Switch` trait which registers the devices common to switches.
In the device registration function, the `RequestChan` param was a move. The problem with this is the driver could save the channel in the associated type and use it during the life of the driver. The channel is only intended to be used to register the set of devices. In this commit, we make the `RequestChan` parameter a mutable borrow which means it can't save it. (Hmmm. can it make a clone()? Gotta check.)
Drivers can no longer clone or keep the request channel they are given. This limits device registration to only when the drivers are first started.
I originally got some of the traits to compile by returning pinning trait objects (i.e. Pin<Box<Future<>>>.) And then the driver manager also wrapped its `Future` with `Pin<Box<>>`. Those were rookie mistakes of mine. Now I find I can return `impl Future<>` for those APIs. This commit corrects that mistake and now there's two levels of indirection and allocation that have been removed.
The `Store` trait methods no longer return `Pin<Box<Future<>>>`. Now they just return `impl Future<>`. This reuired a change in the state of the `core` module since it was storing a `Box<dyn Store>`, which isn't compatible with `impl Future<>`. So instead of storing a pointer to a heap-allocated `Store` object, we now place the `impl Store` directly in the state. This means less use of the heap and no indirect calls to the methods.
Contributor
Author
|
Since making these driver traits will require a version bump for the |
Commit ea238f5 didn't meet the goals I set for it. After some research and help from Gemini, this commit comes closer to the goal. It's still a bit wordy, so future commits may clean it up even more. But this is the first release in which a driver can specify one of a set of standard device naming schemes.
This is the first driver to use the common hardware types.
This is a further iteration on the driver API. I think this one hits a lot of good points: - Drivers need a type that implements the Registrator trait - Removed blanket trait (which caused some problems with drivers that were trying to merge the driver API and Registrator traits) - This version has less `dyn`s, less `impl`s, and less associated types.
This driver now uses the common `WeatherDevices` type instead of defining its own.
- Use latest crate. - Turn on `tcp_nodelay` to decrease write latencies.
We can get the timestamp from the reading instead of saving it twice.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request modifies the driver API so that hardware types can be defined and shared between drivers.