You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We could rewrite the AdapterManager's channel API as follows:
/// A channel, which may have read/write capabilities.pubstructChannel{id:Id<Channel>,kind:ChannelKind,service:Id<ServiceId>,pubproperties:PropertyBag,pubfetch:Option<Box<Fn(FetchArgs) -> Result<Value,Error> + Sync + Send>>,pubsend:Option<Box<Fn(SendArgs) -> Result<(),Error> + Sync + Send>>,pubwatch:Option<Box<Fn(WatchArgs) -> Result<WatchGuard,Error> + Sync + Send>>,// Possibly more in the future.}implChannel{/// Create an empty channel.pubfnnew(id:&Id<Channel>,service:&Id<ServiceId>,kind:ChannelKind) -> Self;}implAdapterManger{pubfnadd_channel(channel:Channel) -> Result<(),Error>}
Pros
This relieves Adapters from having to maintain their own mapping between Id<Getter>/Id<Setter>, actual devices, actual implementation.
Extending this with future capabilities (e.g. delete) should be quite simple.
We can expose a data structure Channel much like this to the REST API, and it should often be easier to use than our current separate getters/setters.
Cons
The current AdapterManager manages to combine various fetch (respectively send, watch) requests by Adapter and send them together to minimize communications. I don't see how to do this with this design.
The text was updated successfully, but these errors were encountered:
Spinoff from an idea by @mcav in #53.
We could rewrite the
AdapterManager
's channel API as follows:Pros
Id<Getter>
/Id<Setter>
, actual devices, actual implementation.Channel
much like this to the REST API, and it should often be easier to use than our current separate getters/setters.Cons
fetch
(respectivelysend
,watch
) requests by Adapter and send them together to minimize communications. I don't see how to do this with this design.The text was updated successfully, but these errors were encountered: