The main line of thinking after following discussions all over the forum about best ways to structure tags, especially with large amounts, is to use a folder hierarchy at the top levels instead of UDTs. This is mainly to not have many potential disabled or 'bad' tags hanging out there cluttering things up.
The main issue though is not having parameters at that top level for all tag property bindings to look for. I can see many use cases for this.
I'd like to mention that tag folders are capable of holding custom properties just like tags and UDT instances, but there is no user interface that will display them or permit convenient editing. They have to be scripted. Perhaps exposing and leveraging these would be a path forward.
I was playing with these same ideas yesterday as both of you mentioned, didn't have much time to test, will do a little more today.
One thing that I didn't like about having an "info" tag is that one would have to manually or script to add an "info" memory tag in each folder and rely on scripting to maintain. I love scripting as much as the next guy and have created several full blown functioning apps, but when it comes to the tag structure, one wrong step and you can lose or worse corrupt the tag structure. I had to fix one once, and it's not easy as a simple restore. Also, I see more continuing maintenance as the info tag expands, which can complicate things for the future or other developer working on it.
Maybe I'm being a little too prematurely bleak, will test more today and report back.
So one thing that helps is that Alarm property bindings allow expressions and access to tags, udts and such. This alleviates my concern about Alarm pipeline callouts based on a parameter. For example, in one older project, each Site (several hundreds) is divided in the tag structure as a UDT (which I would keep organized, but with folders at that level in future projects), each site has a custom alarm property based on the top level UDT param, which makes it easy to send out to that site's roster.
So this leads to my next question, wouldn't it be nice to have tag property bindings have expressions and access to other tags (not to be confused with expression tags)?
Of course it would be nice. If the implementation doesn't crush your gateway hardware.
The fundamental difference between the configuration bindings in UDT members and the bindings in expression tags and query tags, is that the latter subscribe to changes in the tags they reference, when in event driven mode, so they can re-execute to stay up to date.
General tag configuration bindings only execute at tag startup or restart, which is triggered by UDT parameter writes. Alarm configuration properties are more tolerant, because they have to execute when an alarm triggers in order to capture associated data.
Making general tag configuration property bindings subscribe to their references would cause the internal bookkeeping of the tag subsystem to explode. And worse, eventually, because that flexibility would be abused.
What I'm hoping for is some middle ground, limited expansion, whatever, that could be implemented by IA without risking catastrophe.
Have the tag restart manager briefly defer (500ms, perhaps) actual restarts so multiple changes produce a single restart.
The tag manager exposed by that context would need to implement the predefined references and UDT parameter references similar to what is already done for {this} in expression tags. An expansion to the tag manager shim that already implements relative tag paths, perhaps.
This setup would allow atomic tags to parameterize themselves using bindings involving {this.customPropName} or similar. And UDT parameters themselves could be phased out in favor of custom properties via {this.parameterName}, unifying the implementation of atomic tags and UDT members. Perhaps auto-converting on an 8.1 => 8.3 upgrade, or 8.x => 8.5 upgrade.
