Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
A new forum section
I've created a new forum section that is dedicated to trying to work out standard interfaces for various types of devices, so that we can over time begin to create a system that provides vastly more helper functionality, much more auto-generation capabilities, and much more abstraction from specific devices so that devices can be swapped out more easily.

Anyone is welcome to comment in any of the threads. There are some overall discussion threads stickied at the top (and some general info ones that are not for discussion), then a set of threads one per possible device class, where we can sort of hopefully bang out together the requirements for standard interfaces for these various types of devices.

This is something that has been floating around for a long time. I thought about it a lot over a year ago, but felt not sufficiently wise to really come up with these device class definitions on my own, because much of it isn't technical stuff but what's the minimum, broadly supportable features that are required for a given type of device that we could bang into a standard interface that all such drivers could implement.

This doesn't mean that's all they can implement, it just provides a standard, core set of features that can be depended on for any driver that professes to support a given device class.

This is a tricky proposition, since you want it to support as much functionality as possible, however if half of it can't be implemented on half the devices out there of that type, it's not really worth much. Clearly there will be devices that are outliers and they will just never be supportable by such a common interface, but we need to find that subset that can be and that is functional as is possible within those constraints.

It also includes the attempt at standardization of the semantic field types so that others can start to mark their fields in their drivers. Much of what needs to be done can be done at the purely semantic field type level, even if the driver doesn't conform to any higher level device classes.

So, anyhoo, feel free to kick in and put in your two cents about what the minimal functionality of a given device class needs to be, and we can then start from that and see how much of that really can be widely implemented enough that it could be included. Eventually we can come to some useful definition.

Note that we aren't talking about something like the current 'device category' which is somethign that will eventually be replaced by these new device classes. A driver can only be one device category, but many drivers will implement more than one device class. This will allow generic logic that deals with a particular aspect of a device, whether it's the whole device or just some subset of the device's functionality. As an example, something that implements the DIO class provides digital IO. That part of the device's field interface that exposes that DIO stuff will be the same whether that device only implements digital IO functionality, or whether it's part of a larger device (such as an Elk or Omni.) Generic automation logic and auto-generation code doesn't have to understand it's an Elk or an omni in that case, only that it implements a given interface for a type of functionality it is interested in.

You can't start threads in that section, so that it can be well maintained and kept clean. You can reply to the threads that are there.
Dean Roddey
Explorans limites defectum
I don't have classes like you described. I have these classes:


...and a few others... but it seems you're looking for device classes.

Maybe also have standard classes for automation code? Then a generic framework can be pre-built and make complex automation easier?

edit: After reading additional threads. It seems my classes are kinds of wrappers for devices. It will be interesting to see where this will go...
--Kill all the serial ports--
This isn't classes in the OO code sense, but classes as in classifications. So this is more about taxonomy really.
Dean Roddey
Explorans limites defectum

Forum Jump:

Users browsing this thread: 1 Guest(s)