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 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.
That's a totally different approach which could be discussed.But I really dislike using some object members to pass parameters and another member to trigger the processing itself. It seems very awkward to me. The DO members should have some meaning in time, not only at the very moment the processing is triggered.
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).
Adirelle, I see one big problem in your idea and that's how you use LDB.
LDB's DOs are ment to be used by addons that want some sort of data displayed, not for addons that offer a service. While in theory, it would still work, the two sets of objects should be strictly seperated.
Elsia's suggestion is closer to how LDB is ment to be used though every change fires a callback so there is no way to change both the text and the icon for the new message. The only way to do so would be putting everything inside a subtable and replace the current subtable by thatone, resulting in using at least two additional tables.
Elkano, you should took a look at how Tekkub's Cork is designed. Cork modules are DO that provide both data to be displayed (actions to be taken) and functions to execute (said actions). These modules offers both data and services.
Anyway, I admit my design does not take advantage from LDB "property changed" callbacks.
As for Elsia's proposal, a solution would be to have one specific member trigger the display instead of displaying a new message on every property changes. One drawback, IMO, is that you have to configure in the display which messages should be shown or not, instead of choosing in the message providers where they should be sent.
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:
You can do almost everything with it, either internally (like Cork does) and between addons. The second part obviously needs common specs. But I do not think we have to stick to the "data" part of the name.
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.
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.
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.
I've never seen it implemented that way, though, so it's kind of moot from a user viewpoint.
I've never seen a serious request for it to be implemented that way...
As for running this though LDB... seems like we're trying to invent things for LDB to do that it wasn't really intended for or are already covered by other libs that could / do a better job.
As for running this though LDB... seems like we're trying to invent things for LDB to do that it wasn't really intended for or are already covered by other libs that could / do a better job.
According to the LDB wiki, it is intended for no particular purpose : "Due to its simple generic design, LDB can be used for any design where you wish to have an addon notified of changes to a table."
On the later point, I admit LibSink already does a great job (though nothing forbids LibSink to interact with LDB scroll area DOs or even be rewritten to use them).
According to the LDB wiki, it is intended for no particular purpose : "Due to its simple generic design, LDB can be used for any design where you wish to have an addon notified of changes to a table."
This is correct, it can do things like this. However I feel that if LDB was to move this direction it would need either a fairly strict sense of spec or be hosted though a different name altogether with practically the same internal workings.
Rename? Why? It would still be a library which acts as a Data Broker. Simply because it's thusfar been used for FuBar-ish AddOns doesn't mean its name is tainted.
Rename? Why? It would still be a library which acts as a Data Broker. Simply because it's thusfar been used for FuBar-ish AddOns doesn't mean its name is tainted.
im a partily OCD individual, so in head i want a new name for a different needs even if it is the same functionality.
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?
#X-Embeds is not used anymore, it is depreciated
as for
#OptionalDeps and LDB, none. It should always be included in the addon naturally as another file as well as CBH and loaded along with the libs as usual.
Rollback Post to RevisionRollBack
To post a comment, please login or register a new account.
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.
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).
LDB's DOs are ment to be used by addons that want some sort of data displayed, not for addons that offer a service. While in theory, it would still work, the two sets of objects should be strictly seperated.
Elsia's suggestion is closer to how LDB is ment to be used though every change fires a callback so there is no way to change both the text and the icon for the new message. The only way to do so would be putting everything inside a subtable and replace the current subtable by thatone, resulting in using at least two additional tables.
Anyway, I admit my design does not take advantage from LDB "property changed" callbacks.
As for Elsia's proposal, a solution would be to have one specific member trigger the display instead of displaying a new message on every property changes. One drawback, IMO, is that you have to configure in the display which messages should be shown or not, instead of choosing in the message providers where they should be sent.
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:
Let me think about this a little.
LDB basically implements :
- an object registry,
- property change callbacks.
You can do almost everything with it, either internally (like Cork does) and between addons. The second part obviously needs common specs. But I do not think we have to stick to the "data" part of the name.
I've never seen it implemented that way, though, so it's kind of moot from a user viewpoint.
I've never seen a serious request for it to be implemented that way...
As for running this though LDB... seems like we're trying to invent things for LDB to do that it wasn't really intended for or are already covered by other libs that could / do a better job.
But - that was an aside. I like the discussion you guys are having. Its one of the most interesting ones we have had on this forum in a while.
According to the LDB wiki, it is intended for no particular purpose : "Due to its simple generic design, LDB can be used for any design where you wish to have an addon notified of changes to a table."
On the later point, I admit LibSink already does a great job (though nothing forbids LibSink to interact with LDB scroll area DOs or even be rewritten to use them).
This is correct, it can do things like this. However I feel that if LDB was to move this direction it would need either a fairly strict sense of spec or be hosted though a different name altogether with practically the same internal workings.
im a partily OCD individual, so in head i want a new name for a different needs even if it is the same functionality.
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?
#X-Embeds is not used anymore, it is depreciated
as for
#OptionalDeps and LDB, none. It should always be included in the addon naturally as another file as well as CBH and loaded along with the libs as usual.