Authors CurseForge

I think it can be accepted but best by actually just giving an implementation that is ready to use. Here is how I would do the spec though:

do = 
{
  type = "timed event"
  text = "event text" -- Set this when an event happens
  icon = "icon" -- Set this for the next event
  isSpecial = true/false/nil -- Optional. Set this to true if you want to indicate that the event is special (crit, sticky)
}

Remember that each writing to broker field will trigger a callback. So by convention when text is written that is the moment for display update, hence no need to pour(). People can add custom fields to add more semantic information, possibly differentiating between types of events to allow different routing (incoming, outgoing, gains etc).

Instead of using test one could also use a trigger field separately...

Further possible fields could be a time-stamp field, to allow display to also report the time the event happened. But this could be convention and the display can actually just grab the time when the callback triggered. (Only for cases where you want exact stamps from the combatlog that wouldn't be exact possibly).

Visuals are display choice, hence no colors in this spec. Also if it's enabled is with the display. It can be used by as many displays as one desires hence routable to multiple places.

The DOs would be stuff like DO_CT_HealEvents, DO_EXP or DO_Friend_Targeted, DO_Gold_Looted. People configure their SCT based on what DOs they install and route them to the parts of the display where they want them, which may be multiple. Boss mods could really easily support this I think.

If anyone wants to route new data that's easy or create new types of displays (route to chat window or what-not) that's also possible.

Quote from Adirelle

Actually I proposed this because people were, a few pages earlier, in search of DO specs that would be different from existing ones. I think that a good example but I didn't think a moment it would be accepted.

I don't think it's a bad or invalid idea, and I'm not resistant to it. I just want to make sure that if it were implemented, that it would be done right (i.e., become something that I'd find worth using).

I hear you, but that's the nature of timed events. You can do it by function calls or by triggers. I agree that having a data carrying field trigger is awkward and people will have to make copy of data for persistence. I don't think that's a real problem though. Anything else is more complicated (i.e. trying to do persistence in the broker, needs locking etc).

There is no issue with passing functions. In fact any type I know does this in one way or another.

I agree on your point with config. That's a tricky issue in many cases. The way you solve this - in a way - is to register what would be the displays (rather than what we usually think of as the DO) and let the data feed into the display via pour(). I think this is a really good point even in a broader sense. Even for launchers/data sources it might be neat to be able to go into broker_whatnot and tell it to show up in display A and D.

A way to do that might be to actually create a table carrying displays that accept a LDB type along with Activate(), Deactivate() calls. The you can do the route-this-to-chat from the DO as well as have the chat enhancing display override that choice.

Here is how this works right now:

LDB DO registers itself. Display can find all DOs and gets alerted if new ones pop up.
Displays do not register themselves. DOs cannot find which displays are present or control how they use them.

But if I understand you correctly essentially you are saying, well lets think of DOs as those that provide a service to be found, hence clearly what we want to be found by the user is what should be the DO. In this view it makes perfect sense to make the "displays" i.e. the SCT, chat-mod, combat-event-frame etc the DO.

Maybe there really is just a case for LSB (libservicebroker) and LLB (liblinkbroker) with the following discovery semantics:

LDB: A -> B
LSB: A <- B
LLB: A <-> B

Let me think about this a little.

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.

Quote from sylvanaar

Just as an aside. LibSink isn't really limited to one output. You can embed it multiple times if you want more than on output. Perhaps embed is the wrong term. You can give it multiple storage areas, and add it more than once to your options table.

I've never seen it implemented that way, though, so it's kind of moot from a user viewpoint.

Hi!

1. What is the tag policy #X-Embeds: and #OptionalDeps: tags for LibDataBroker-1.1?

2. What is the embedding policy for addons nolib version?