Authors CurseForge

Short form, just so I understand: port LibStub (done) and CBH (done) and adjust both tocs accordingly. I don't have to worry about the minor version for CBH or LDB because Rift has internal version checking.

Next, port LDB pretty much as is, removing the references to the minor version as well.

In MyAddon, use OrionShock's code above. I could replace local eventFrame = {} with

-- put this at top of first Lua file loaded
local MyAddon, addon = ...
_G["MyAddon"] = addon

-- put the rest in main addon file
addon.eventFrame.cbh = CBH:New(... what OrionShock said)

In CBH's toc file, I need the following two entries

--@no-lib-strip@
Embed = {
    LibStub = true
}
--@end-no-lib-strip@

Dependencies = {
    LibStub = {"required", "before"}
}

LDB's toc can be a bit more complex. I am providing a toc, so it doesn't need to be hard-embedded.

--@no-lib-strip@
Embed = {
    LibStub = true,
    CallbackHandler = true
}
--@end-no-lib-strip@

Dependencies = {
    LibStub = {"required", "before"},
    CallbackHandler = {"required", "before"}
}

Getting to BrokerBar ("MyAddon"), the toc would then look like

--@no-lib-strip@
Embed = {
    ["Libs/LibStub"] = true,
    ["Libs/CallbackHandler"] = true,
    ["Libs/LibDataBroker"] = true
}
--@end-no-lib-strip@

Dependencies = {
    LibStub = {"required", "before"},
    CallbackHandler = {"required", "before"},
    LibDataBroker = {"required", "before"}
}

Quote from Adirelle

Wouldn't the transitive dependencies be resolved by Rift so you do not need to list all dependencies in your addon ?

Probably, but I am covering redundancy and all my bases in case people want to install disembedded. And unless there is some uber-clean way to perform that in MyAddon's toc, the above is the only way I know how.

The point being, just like WoW, addons and libs should come zipped with whatever support libs they need, but if you run disembedded, then you'd want one copy of LS, CBH, and LDB each. Not three LibStubs (root, with CBH, and LDB) and two CallbackHandlers (root and with LDB).

Quote from Adirelle

By the way, what OrionShock gave you is some kind of standard "Rift event system to CBH" bridge. This is basically what AceEvent-3.0 is doing with WoW events. This could be a small library on its own.

Good point.

@OrionShock: I notice you have UnregisterEvent, will that also work for UnregisterAllEvents?

eventFrame:UnregisterEvent(Event.Some.Event)
eventFrame:UnregisterAllEvents()

If not, it shouldn't be too hard to add that. Just string.match Event.* and table.remove them.

Also, does this allow

eventFrame:RegisterEvent("Event.Some.Event", "BobsEvent")

function eventFrame:BobsEvent() end

I just noticed this line of OrionShock's bridge code

tinsert(eventTable, { function(...) eventFrame.cbh:Fire(event, ...) end, "MyAddon", "SomeLabel")

If I make this into a lib, say RiftAceEvent-1.0, then there is no way to know what "MyAddon" and "SomeLabel" are ahead of time. Is there a way to make it more neutral?

Yes, both are indeed for debugging. It gets tricky with the bridge code when you are registering for more than one event. "MyAddon" would remain the same, but "Label" would change. For example, if you had a command line process function and you also registered for some combat event, the first lable might be "MyAddon's command function" and the second would be "Handle MyAddon's damage done".

As strings, you can name labels anything, from "Damage" to "Damage done filtered by player".

For now, I will use the bridge code as part of my addon directly, and try to figure out how to break it into a seperate library later.