Side library/module for Event Hooks

[YoshiEnVerde]

I'm opening this issue to follow a converstion that started on #7:
OSHI having the ability to add event handlers to things like changes in values, errors in drivers, etc.

This was brought up by @cilki , and I responded that we should avoid such things in the standard library, to avoid the impact of the extra functionalities to performance, when it's not part of the base requirements of the OSHI library.

My idea for this follows from another idea that we should split the different layers of OSHI5 into separate modules. If so, we can implement multiple OSHI libraries, that connect at different levels with the base modules.

[YoshiEnVerde]

@cilki 's OP:

The reason I intended users to interact with API classes (components) rather than interfaces (index) is because it would be beneficial for the user to do other things not defined in the interface.

Here's what I mean. A CPU interface would define String getModel(), but it could also be desirable to have another method that returns the attribute itself: Attribute<String> model(). This object would contain metadata like timestamps, but most importantly would be AutoClosable so OSHI knows when the user is done polling the attribute. I'm also imagining an addListener() defined for attributes which adds a callback that receives change events.

These methods shouldn't be added to the main interface because then the drivers would need to implement them as well.

Edit: Although now that we've agreed to generate the API, we could just make a separate interface for the drivers.

[YoshiEnVerde]

My original response (the relevant part at least):

Not saying the use cases aren't there, or interesting, just that we should focus on designing and implementing OSHI here, and leaving any high level functionalities to a separate module.

The problem with adding extra functionalities is that we start clashing with the try to be more performant part of the OSHI design.

What we can do, is build each layer of the library as a separate module (or set of modules). For example, a module with the Win Drivers, one for the Mac Drivers, one for Components, etc.

That way, adding a module with the functionality you want would be as easy as adding another module to the OSHI catalog, that depends on the Strategy/Driver level modules, and works as a standalone from the standard OSHI library

[cilki]

Also we first discussed the possibility of a polling engine in oshi/oshi#548.

[YoshiEnVerde]

Full conversation that continued in #7

@cilki

We discussed a polling engine to supply change listeners a while back and decided it was best for another artifact. I was just trying to setup the base design so it could easily support such extensions in the future.

One more tangent: OSHI doesn't currently have the notion of open/closed for anything, but I think it would benefit from having stateful drivers/strategies. What do you think about that?

@YoshiEnVerde

The reason I intended users to interact with API classes (components) rather than interfaces (index) is because it would be beneficial for the user to do other things not defined in the interface.

Here's what I mean. A CPU interface would define String getModel(), but it could also be desirable to have another method that returns the attribute itself: Attribute<String> model(). This object would contain metadata like timestamps, but most importantly would be AutoClosable so OSHI knows when the user is done polling the attribute. I'm also imagining an addListener() defined for attributes which adds a callback that receives change events.

These methods shouldn't be added to the main interface because then the drivers would need to implement them as well.

Edit: Although now that we've agreed to generate the API, we could just make a separate interface for the drivers.

One thing I've realized about your post, related to the Attributes, is that you're asking for a possible AutoClosable on the Attributes themselves. My guess would be to keep updating them until you don't need to?

First of all, our current work (OSHI3) on the code that would go into the drivers doesn't contemplate keeping a resource open for variable lengths of time. We request the value from the system, we get it back, done. Any update means doing the full request once more.
That's even the only approach available for most of the requests.

Second, what you're asking for the Attributes would be the reason why I split the response data into Response, Attribute, Entity and Component: The first three should be static. Once requested, they're fixed. That allows for the user to have stable and reliable data on hand. The Component is updateable, returning a new set of Entities on every update.
With that, what you ask for in states is, technically, part of the Component; while metadata can easily be argued in favor of, or against, as part of the Result objects.

We discussed a polling engine to supply change listeners a while back and decided it was best for another artifact. I was just trying to setup the base design so it could easily support such extensions in the future.

I actually find the use case to be a very useful one. I just don't see this being a part of OSHI itself. For setting things up for the capability, I just raised a new issue, since I do find it to be a perfectly valid reason for some details in the design approach

One more tangent: OSHI doesn't currently have the notion of open/closed for anything, but I think it would benefit from having stateful drivers/strategies. What do you think about that?

This is one of the reasons why we'd have Drivers/Strategies in a separate layer from the Caching and API itself. If we need to, we can implement Drivers that are not stateless (I actually encourage that for some drivers). However, the way the driver works should not reflect on the way the API works, since the whole point of a Driver Pattern is to abstract such concerns from the API.

What we can do is add/leverage the configuration layer, to be able to set those up.

@cilki

the way the driver works should not reflect on the way the API works, since the whole point of a Driver Pattern is to abstract such concerns from the API

The only problem is, how can you determine when to release a driver's resources without a cue from a higher layer? Making the lowest layer stateful introduces a session-like architecture to the higher layers.

@YoshiEnVerde

Last response, and then let's move this to it's own issue, since this one is supposed to be about naming conventions ;)

The only problem is, how can you determine when to release a driver's resources without a cue from a higher layer? Making the lowest layer stateful introduces a session-like architecture to the higher layers.

Yup, that's an issue that we do need to address as part of the Driver's design/implementation. It should still not be part of the general API.
By that, I mean that the state of the Drivers should not be something that impacts on the Entities/Attributes/Results.

If we need to, we'll add some management module that handles that. Or we'll add a way to set this up, or to open/close the resources, or whatever we might need.
But it should never be delegated to an element five layers of abstraction away.

For the case you proposed back in oshi/oshi#548 , for example, with the ability to set only specific values to be updated on polling, and avoiding others, we'd just as easily have a configuration value that disables certain values from being fetched by a Driver.
This is even something that can be done programmatically, just by replacing a value in the app properties map.
If we have such a configuration value, we can just as well have some kind of ConfigHandler/ConfigManager that has methods to set all those without needing to blindly set values in the properties themselves.