Object oriented file based definitions

[mgeramb]

I'am very happy with the file based definition of things and items. But I suggest that we build a more object oriented format to provide all stuff which is related to each other in one file.

E.g:

// Bridge with things and channels
Bridge amazonechocontrol:account:account1 "Amazon Account" @ "Accounts" 
{
    Thing echo alexa_wohnzimmer     "Living Room" @ "Living Room" [serialNumber="XXXXXXX"]
    {
       Player Echo_Living_Room_Player "Player {channel="player"}
       Dimmer Echo_Living_Room_Volume  "Volume [%.0f %%]" <soundvolume {channel="volume"}
    }
}

// unlinked items
Switch Echo_Little_Louder    "a little bit louder" 

// sitemapparts (should be useable inside of a sitemap definition)
SitemapPart alexa
{
    Text label="Alexa Wohnzimmer" icon=""  
    {
                Default   item=Echo_Living_Room_Player
                Slider    item=Echo_Living_Room_Volume
   }
}

// related rules
rule "Ein bißchen Lauter"
when 
    Item Echo_Little_Louder received command ON
then
    var volume = (Echo_Living_Room_Volume.state as DecimalType).intValue + 5
    Echo_Living_Room_Volume.sendCommand(volume)
    Echo_Little_Louder.postUpdate(OFF)
end

Advantages:

• Channels can be linked with the short name
• Easy sharing of complex examples to other users
• Less switching between files, while programming openHAB

Let's start the discussion about this proposal now!

[rkoshak]

What about Rules that are associated with multiple Things/Items?

There is already going to be a proposal to replace the current syntax with some other format for which there are both readers and writers. The current format only supports readers, not writers. The primary problem is that because of this lack and the radically different formats between how OH stores stuff done through the REST API and the text configs, there is no migration path between the two. Thus those who start with one approach have to virtually start over from scratch to migrate to the other approach.

Also I think the plan is that NGRE will become the default for OH 3 and I'm pretty sure it would not be compatible with this sort of approach. Maybe with JSON formatted Rules but those are intended for UIs to build, not text based as proposed here. For text based Rules, the formats of the rules file need to be in the programming language chosen to implement them.

I could also see this exacerbating the loading order problems we are currently seeing where Rules start executing before everything else has loaded because there will always be cases where you need to write Rules that have to deal with Items defined in some other file.

The sitemap will require extensive modifications to allow definition of it using multiple files. Personally, I'd rather see that effort spent on making sitemaps editable/creatable through the REST API.

A change like this would be very disruptive to those who already have text based configs. If we are going to be that disruptive, we may as well solve other problems too, like addressing the fact that we don't have a writer.

Look to see there is an Issue already created that discusses the file formats (I think one was opened) and contribute to the discussion there. I could be mistaken (i.e. don't take this as a veto) but I don't think this will come to the AC until and unless the developers/maintainers cannot come to a consensus on how to proceed. Then the AC can be called upon to break the impasse.

[mgeramb]

What about Rules that are associated with multiple Things/Items?

You write a file containing only rules

There is already going to be a proposal to replace the current syntax with some other format for which there are both readers and writers

I know this discussion, but my AC is not related to the format of the file. It was only an example how this could look like

A change like this would be very disruptive to those who already have text based configs.

Why? Only small extensions are needed to the current syntax, if we want have it in this way, the currently configuration could used without modifications. But this is not a must. We can change the syntax completely too.
Please read the AC as:
Provide the possibility to have the configuration of Things, Items, Sitemaps, Rules in one file
Which should not mean, that you can have only one file.

contribute to the discussion there

Please give clear instructions, which proposals are welcome here and which should be discussed in the other forum.

[rkoshak]

The purpose of the AC is to be an authority to appeal to when there is an impasse among the developers and maintainers of the various parts of OH or to help maintainers from different parts of OH to come to a decision on how to address a cross cutting change. It is not intended to be a place where dictates are are handed down from on high.

As such, a change like the one proposed should first go to the developers and maintainers by filing an issue. Only if the maintainers cannot come to an agreement on how to proceed would the AC step in to make a decision.

I know this discussion, but my AC is not related to the format of the file. It was only an example how this could look like

Which is why I suggest you go to where the developers who are working on the changes to how the text based configs will be handled in OH 3 are working and discuss this idea with them. They are ultimately the ones you need to convince to adopt this approach. If approved by them, this would only apply to the new OH 3 file formats. Only if there is disagreement among the maintainers would the AC come into play.

But given what I know about the NGRE, the Rules will likely never be a part of this as they must follow the syntax of what ever language they are written in. The current Rules DSL should be deprecated by OH 3 is released.