Talk:AddOn communications protocol

Group leader

Is 'groupleader' in AddonCommRegistrar needed? let's say there are two comm addons, on leader change the first leaves the channel and schedules to join the new channel in 2seconds, the second addon immediately sees that the channel isn't available anymore (and maybe does something, like informing it's clients etc) and schedules a 'join' in 1 second. After one second the second addon joins the new channel, after another second the first addon sees that the first channel is available and doesn't need to do anything. I'm doing JoinChannelByName() even if I'm already in the channel and I haven't seen anything bad happen, joining the same channel twice works fine.

No, frankly me and a few others (Satrina) would be totally fine with CommRa(Checksum). But the though twas that we wanted some semblance of user-readability in the channel name. It'll help people know they're in the correct channel, and they won't freak out at the "weird channel with all these numbers" they keep seeing. --Tekkub 17:31, 9 July 2006 (EDT)

I didn't mean the groupleader name in the channel, but the 'groupleader' variable in AddonCommRegistrar. IMO addons don't need to know whether another addon is already preforming the channel switch or not. They just need to check if the user still is in the old channel, if yes then leave it and schedule a 'channel join' in 1 second. And then again, if another addon already joined the new channel, fine, if not, join it.

OMG inline replies! I'm too used to forums and not used to wikitalk, this is neat :) I'll tweak my replies to fit that "standard". I see what you're talking about and yea, it's not needed. I had put that there when I was thinking "only one mod should perform the channel switch", but it's not a problem if many duplicate join channel calls are made. I'll tweak that. --Tekkub 08:49, 10 July 2006 (EDT)

Sky

Sky does all of the stuff you discussed. Why not just take it and improve it to work the way you need? -- AlexanderYoshi

The main goal is to create a standard! So nobody has to rely on one specific addon.

Some people don't like Sky. Some people don't need all those extras. Some people flat out REFUSE to use Sky or any mods that use it, for whatever their reasons. People like to hold grudges and can be quite fickle you know. The intent here is to provide a protocol everyone can use. Different mod developers can share the same channels and not interfere, they can write their own libraries, and most importantly, they won't be making users fill up their chat channels with communication channels that are only used by one mod.

The intent is to define a simple underlying protocol that we can all share, if you want all those extras Sky has, by all means use it. Not everyone wants to though.

--Tekkub 17:31, 9 July 2006 (EDT)

If people don't want to use Sky, what is wrong with using the Sky channel naming scheme? Fine discussing a new protocol, but do none of the existing comm systems have any redeeming qualities does it all have to be something rewritten from the ground up? Sky is quite polished, I can't imagine there is nothing good in it, seems grudges make people blind. Gryphon 11:59, 11 July 2006 (EDT)

Alex, the main reason was talking with the authors and realizing that Sky was more of a "Kitchen Sink" of communication addons, and in discussions it was mentioned that backwards compatibility was an issue. The goal here is to make a fresh start, and let the authors implement the portions of the comm recommendation that they see necessary. This lets addons communicate alongside other addons without needing external dependencies or a lot of code to do so (The hash function is really the only code that needs to exist across addons)

--Cladhaire 14:22, 10 July 2006 (EDT)

For example, I'll be using this for the DKP and attendance tracking addons I wrote for my guild. They communicate extremely infrequently (every half hour for attendance, whenever there is loot assigned.) Using Sky for these would be such enormous overkill that it wouldn't even be funny. I'll write a very lightweight, embeddable implementation of the protocol and be done with it.

--Satrina 21:23, 10 July 2006 (EDT)

CheckSum

The mantissa part of LUA numbers (assuming IEEE double) has 52 bits. Encoding a guild name consisting of 30 'z' characters (ascii value 122) would result in a counter of more than (122*17)^30 which is roughly 2^340, which would have considerably more digits than the IEEE double type. Special characters have a even higher ascii value. I'm not sure whether this is relevant or would result in more collisions than a computation with exact values, but you might want to take the modulo at each iteration.

--crobi 15:16, 10 July 2006 (EDT)

The current checksum should be capable of storing well over 50 (fifty) \250 characters (that's what I tested with initially, to ensure we wouldn't approach any limits imposed by the IEEE 754 standard. I am currently able to store numbers up and beyond 6.33e+300 in the standard LUA number and I will test this afternoon in a WoW environment to ensure we won't approach the limitations. Given the limits, I will change the algorithm to take a modulo if the number is larger than 1.0e+150 (which shouldn't affect the results for any guild names that the current edit box allows (24 characters). Anything that manages to breach the 1.0e+150 limit will be wrapped and would give different results compared to the last hash algorithm-- but that shouldn't be an issue here.

--Cladhaire 14:08, 10 July 2006 (EDT)

I've changed the algorithm entirely, just so we dont have to be concerned with anything like this. I tested the hashcode() function from java and while it did almost as well as the custom one we had written. 6 collisions out of 2,000 guild names isn't too bad considering it doesn't need to be a unique identifier. Thanks for your feedback.

--Cladhaire 18:21, 10 July 2006 (EDT)

ChatFrame Filtering

I wouldn't put that into the protocol specification (technically it doesn't belong there). Sometimes I want to see which messages are being sent to the channels and if someone elses addon hooks the ChatFrame function I have more or less no other option than disable the addon. The channel shouldn't get visible during normal operation, if it gets it's the Users' fault or another addon played with the channels and screwed something up -> fix the other addons and tell the user not to play with the channels.

Hiding channels from the users chatbox is an inconsistant pracice at best. Users can accidentally toggle on a channel and not know how to turn it off. Simply supressing the messages from ever bing displayed for the enduser is the best option IMO. It's a fairly trivial matter to write up a mod that will take channel messages on the Comm channels and print them to the chatframe directly, if you want to view the text. But in the end, the numer of people who need simple "it just works" filtering in place far outweighs the people tha will want to see the messages coming thru. I'd like to believe anyone wanting to see those messages is smart enough to dabble in a little lua code, because they shouldn't need to be looking at the addon messages if they don't know how to work on an addon. Heck, a good library for this protocol could have some sort of "Dump messages to chatframe" toggle that devs could turn on if they want to see this stuff. --Tekkub 13:17, 10 July 2006 (EDT)

I prefer the idea of a debugging flag in the comm library to allow the messages to go to the chat frames, yes.

--Satrina 21:25, 10 July 2006 (EDT)

Global Registrar

The question is, how much do we need to save in the structure?

• list of addons actively using a channel
• channel throttling
• chatframe hook established

Strictly speaking only the addon list should be part of the protocol, everything else is just luxus.

I would choose this structure:

AddonCommRegistrar = {
    ["global"] = {       -- or "CommGlobal"? - but not the actual channel name
        AddOns = {       -- list of addons using this channel
            ["Addon 1"] = true,
            ["Addon 2"] = true,
        },
        NextMessage = 0, -- GetTime() of the next message that can be sent to the channel
    },
    ["guild"] = { ... },
    ["group"] = { ... },
 
    Filter = true,
}

Why I've chosen sybolic string constants as table keys? The real channel name (with prefix,checksum) is kinda bad IMO because each addon would need to register itself everytime the channel name changes. And most of the addons don't disable themselves when the raid leader changes. Using the real channel names could also lead to the situation where the old channel isn't left because an addon didn't save the old channel name and can't unregister itself from the old channel.

On leader change, each addon is free to leave the old channel and join the new one, there is no need to inform the other addons that the old channel was left or that some addon already joined the new channel. That akes the 'groupleader' variable in AddonCommRegistrar onsolete.

It also should be noted that hooking ChatFrame_OnEvent() is optional and doesn't need to be done.

Well the intent of the registrar is not to provide any executable code, simply because it is not an embed and can't be upgraded easily and all that jazz. It's more intended to be a simple messageboard where addons can check to make sure they're not going to mess up another addon by leaving a channel or wasting their time putting in a filter when one is already in place. There's no way we can "force" an addon to not interfere with another by leaving channels or whatnot, but the registrar table would provide a sort of "community awareness" that would help those who use it not hurt each other. --Tekkub 13:23, 10 July 2006 (EDT)

Should the current channel be put in the above structure? Seems like it would save resources, although it might up to the addon implementing the structure to keep track of that. FryGuy 10:06, 11 July 2006 (EDT)

I think the full channel name should be used, at least for guild and probably party/raid too. We can't restrict people from joining a different channel anyway, and there may be cases where a player in an alt guild would want their addons talking to the mait guild's channel. We don't want mods closing the channel when someone else is using it, even if it's not the player's current guild's channel. --Tekkub 11:48, 11 July 2006 (EDT)

Missing messages when raid leader joins?

The current spec says to leave the current channel, THEN join a new one after a second when the raid leader changes. However, this may cause some messages to get lost during this event. Could you join the new channel first, (and keep receiving messages on the old channel as well as the new), then leave the old channel after 10 seconds. This way if there's a sync or something going on, none of the messages would be missed. However, this may cause too many channels to be joined, and break things. Perhaps only do it this way if there's not 10 channels already? This also might cause the channels to be renumbered if the user joins a channel in between and annoy the user. FryGuy 10:10, 11 July 2006 (EDT)

Satrina and Cide say users don't like their chat numbers switching around, and the leave then join method prevents this from happening, and it prevent the 10 channel issue too. I think the cleanest solution is to just delay sending any messages on the new channel for a few seconds to assure that everyone is in it. How does CTRA handle channel changes due to rebroadcast? Does it delay or just assume once your client is in it's all good to go? --Tekkub 11:45, 11 July 2006 (EDT)