Two issues with that plan... every display would have to be updated or risk missing DOs with multiple types. Also, what about key naming conflicts? "text" might be used for different things in different specs... what if a dev wanted to use both.
I'll raise the question again... what is wrong with simply registering multiple DOs? It's not that hard to do, and it's really simple to update them all at the same time in your event handlers.
.text is the only required field, it always has been. If you can't wrap your head around all the optional shit, don't use them. They were added by people that think they needed extra crap. .text is the only thing you can rely on every display handling correctly.
This is EXACTLY why I think status bars should be their own spec.
It makes more sense as a separate spec to me. There's no reason to try to cram every possible feature into one spec, and status bars do not fit the "data source" spec... that is designed around displaying textual data, not graphical bars. It's not hard for your addon to just provide two different DOs, one for each spec.
Besides, as a separate spec, it's easier to track what displays support it.
I'm sure a secure data source spec could be made, but it wasn't put in the main spec because secure buttons bring in all sorts of wonderful issues, and the spec is about showing data, not performing actions, especially secure actions.
Personally I think if it requires secure actions, it's better you make your own UI for it.
Using LDB to replace Sink, that's a damn neat idea. Only problem I see is that currently everything that uses LDB is using strictly defined fields. You might need to use a "signal" field to note when a value has changed. For example, maybe you're always writing the same value into the DO... "PoM ready now!", but you would need a way to tell the display that the data needs to be shown. A simple integer field that you increment could work.
1) Localization is totally the DO's problem, label or not. The display can't make up for a DO that provide a label but doesn't loaclize it.
2) Yes, people SHOULD follow the spec. The spec says that .label is the title, why is there confusion that .text ISN'T the title?
3) No, I don't need it and don't care. If a display chooses to implement that, then they are choosing to go beyond the spec and do something that's it's been recommended they don't do.
Seriously, this runaround got old months ago. If you don't like the spec and want something more TAKE MATTERS INTO YOUR OWN HANDS AND IMPLEMENT WHAT YOU WANT. That's what I did with LDB, and I'll be damned if I'm going to take shit about my design decisions. The whole damn spec system is open for this exact reason.
That "endless discussion" is exactly *why* I pushed this out with recommended specs. If we'd have waited for the design to be agreed upon, well we'd all still be in fubar. The library was designed to be WIDE FUCKING OPEN so that the people that didn't like my spec could just make their own. You know, put the money where your mouth is, like I did. The fact that, frankly, everyone except two people has liked my specs... well I think that says that they are a marked improvement over the old fu/titan designs.
And Tris, I can't "enforce" the specs at all, and I totally understand that and designed around that. It's just that no one has come up with anything that the other developers would consider "better".
Sylv, why the distinction? Because they are two different things and some of us don't like our data displays cluttered with plugins that don't display data. Back in the Titan days people discovered that they could make these "plugins" even though it's not what titan was designed for... and they ran with it because there was no better way to do it. In LDB there is. People that want the old titan design can write their displays that way, and people that don't won't have to take extra mesaues to try to determine if a data feed is a useless launcher.
Also this design allows devs to add launcher support with a tiny little if block and no embeds, so there's very little reason to turn down people that ask for it, unlike people asking for fubar launcher plugins and all those big libs you need to pull that off...