Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Device Classification Discussion, Part II
#1
Now that the device class and V2 stuff has come so far along, the previous discussion thread was pretty much a waste of space because so much spilt milk has passed under the bridge by now that all of that discussion in the other thread could only be misleading. Many things have been settled and having all of that pre-settled discussion would just confuse someone coming along later and trying to figure out what is going on.

So I'm going to toss that one and start a new one that resets the baseline to the current facts on the ground and current thoughts about moving forward.

Recapitulation
[INDENT]Just to keep from losing sight of the original reasons for all this, which I'd definitely done and had to really get myself wrapped back around it:
[INDENT]Consistency of device interfaces. A (or an) historical really bonehead technical mistake I made was to just allow all drivers to go their own ways and not attempt to force consistency onto them. In my own defense, even a decade and a half later it's very difficult to figure out how to do this. It's very complex and always a compromise of some sort, no matter how clever you try to be. Even now after a couple releases into this process, it's still somewhat murky.

Auto-Generation. The lack of consistency always prevented us from implementing any real helper tools to auto-generate customization. Even the small amount of progress so far in 4.5 has made a big difference to the auto-generation system. It will get a lot more powerful moving forward.

Customization Reuse. One of the fallouts of that historical misstep is that it's always been very difficult to create user logic or interfaces or any other customization that would work beyond the specific gear it was designed for. This is a huge liability. It would be a huge improvement if you could swap out this device for that device and have everything basically work, possibly with some configuration of course. And the ability to create logic that can be easily reused would be as well.

Though the auto-generation system will be a fertile ground for utiliziation of standard interfaces, I hope it isn't ultimately the biggest one. A major benefit of this stuff will be the ability to create truly reusable logic and interfaces. Autogen makes it easier to get non-customized content, but really reusable logic and interfaces makes it far easier to folks to customize the product, using pre-fab building blocks. Of course this requires very strict standardization to work.

The two aren't totally separate either. The auto-gen system could spit out stuff that can be reused in various ways for customization purposes, i.e. extending the auto-generated content more easily. Some of it it may use itself, and some may be purely to aid in that extension.

Standard System Functionality. Another obvious application of this standardization would be standard functionality that works in terms of well defined interfaces, which we couldn't really do before. V2 should allow us to create more standard functionality for things like occupancy simulation, irrigation, security, power use optimization, and so forth.

Simplification. We really want to make the system easier to setup and ultimately to customize. It's arguable whether these changes will really make the product significantly easier to customize. But the auto-gen stuff will make it easier and easier over time to set up for basic functionality. Other stuff that will be made possible, such as the standard system functionality mentioned above, will lead over time to easier customization, so an indirect relationship but the standardization is key to that.
[/INDENT]

The answer (or our answer) to these issues was the creation of standardized interfaces called 'Device Classes', which define specific types of functionality that drivers can implement. These are more 'fractional' than the current device categories, in that they often don't generally imply any sort of overall device type, but expose specific types of functionality, e.g. power management, audio/volume management, source switching, and so forth. Most drivers implement more than one, and sometimes a good number of, device classes depending on what functionality they support.

This is very important because it means that you don't have to know anything about a specific type of device to manipulate its power state or its volume. As long as it implements a given interface you know how to use, you can do your thing to any driver that implements that interface.[/INDENT]

Setting the Bar
[INDENT]The big thing we need to do is understand the ramification of these desired outcomes and decide where we can 'set the bar' for the standardization of these device classes. In other words, at what point can devices just not be supported within the V2 system, because doing so would drag everyone down to far too low a level. This is a core issue. We want it to be as accomodating as is reasonable, however every accomodation means more inconsistencies that the users of the system have to deal with themselves, instead of it being dealt with implicitly as part of the defined device classes.

The problem is that, if your purpose is to allow customization that deals with a given type of device functionality, you must be able to assume that any driver that implements that interface reacts in well defined ways, i.e. implements the semantics of that device class, not just its field interface. Every deviation allowed is a deviation that customization (and CQC itself) must deal with every time it uses that device class interface. And it quickly begins to create a situation where customization will not really be reusable or transportable to another system, because people creating that customization will never deal with all of the possible variations, they will only make sure it works with their gear.

If we require very stringient standards for the device class interfaces, so that drivers have to meet the requirements of the device class, that minimizes ifs, ands and buts, and that in turn makes it easier to create quality customization content. The inevitable result of that is that devices that are less automation capable will either not be supportable, or it will require a good bit more complexity in the driver itself so that the driver can make up for the lackings of the device.

Obviously we don't want to arbitrarily make drivers harder to write. But, ultimately, there are vastly fewer drivers and driver writers than their are customers and installers creating customizations. If putting more burden on the drivers makes it far easier to create adaptable, reusable logic, then within reason it's a win.

We obviously also don't want to arbitrarily leave devices out of the V2 fun. But, if supporting them means that we have to lower the bar too much, that's not a win. It makes everyone suffer for the lackings of a minority of gear. We will accept some compromises in the sense that some gear may have functionality above and beyond that required by our standardization requirements. That functionality will not be accessible via V2 interfaces, though it can always still be exposed via non-V2 fields if you want to deal with it in a non-portable way. And some burden may be placed on the creator of customization to do things that aren't strictly required by his own gear, because that allows the customization work even with less capable gear.[/INDENT]
Dean Roddey
Explorans limites defectum
Reply


Messages In This Thread
Device Classification Discussion, Part II - by Dean Roddey - 07-25-2014, 03:31 PM

Possibly Related Threads…
Thread Author Replies Views Last Post
  Device Class Index Dean Roddey 1 3,231 07-25-2014, 05:11 PM
Last Post: Dean Roddey
  Semantic Field Type Discussion Dean Roddey 18 18,344 06-23-2014, 08:29 AM
Last Post: Dean Roddey

Forum Jump:


Users browsing this thread: 1 Guest(s)