Thank you for your interest in the Quick Jump Daily Digest. Get notified of all new content on QJ.Net in our free Daily Digest.
To receive our Daily Newsletter, you must first be a member of the QJ website. Becoming a member is FREE and easy to do. To get your own
membership, click here to sign-up.
If you are already a member, click here to log-in. You
can then click on "Newsletter Settings" to customize your daily digest experience.
This addons manages two communication channels ("guild" and "raid" if the player is in a raid) and allows addons to use a RPC mechanism. It's based on raidCommander which I've written to show that CT_RaidAssist is overly complex and that the channel comunication code can be done with a much shorter (and thus easier to maintain) lua code. commChannels now allows any addon programer to perform RPC (remote procedure calls).
Maybe this addon just got more complex than the CTRA code, but it allows many addons to multiplex their messages (ICC, Inter Client Communication, or however you call it) into one channel. Todays addons use one channel per addon, one for CTRA, one for each damage-meter, one for each guild/raid-managment addon, that can fill up the available chat-channel slots really fast, especially when you also join channels manualy.
How it works ============
Whenever there is need to join/change the chat-channels, commChannels generates a unique name for the "guild" and "raid" channel and joins them. For each channel, there is a list with all installed channel-modules, a channel-module is uniquely defined by a name. There usualy is one channel-module for each addon, but it's also possibly to register more than one channel-module from within an addon. Each channel-module also has to provide a interface. This interface contains functions that the module provides. Upon recieving a RPC-request, each client looks up if it has installed the module, if yes, it looks up if the module interface provides the requested function, and if that's also true, it calls that function with the given arguments.
Messages which are sent to the communication channel are encoded in a very simple way so that each request can be parsed efficiently. The argument list is serialized from lua-objects, so it may contain strings, numbers, booleans and tables.
channelModule:moduleFunction([arguments list])
for example:
rCo:statusCheck() rCo:statusReport("not-ready")
-- just an idea how spell cooldowns could be reported: userCache:reportCooldown("Innervate", { spellStart = 1856, spellDuration = 360 }) -- or a more portable way: userCache:reportCooldown("spell:74:0:0", { spellStart = 1856, spellDuration = 360 }) -- where "spell:74:0:0" can be parsed just like an itemlink, each ID has to be defined globaly, 74 would be Innervate on an english client, the two remaining IDs could indicate spell upgrades through talents or items.
This example is from the raidCommander code which I've ported to the commChannels interface.
http://dbservice.com/tom/commChannels.txt Changes : 0.0.0.3 ======= o better error handling in object serialization o reworked message buffering code
0.0.0.2 ======= o security update (don't allow function calls in the argument list) o don't join channel that don't have any modules registered o allow to destroy (unregister) modules
