[thoughtlover]

Right off I'd like to praise the idea behind CastCommLib. I've always thought such a library would be useful if people would all write towards it: multiple addons sharing spell target information. I've been thinking about the implementation, here are my thoughts:

Summary:
In my opinion, UNIT_SPELLCAST_ trigger events for units other than just the "player" should be used in addition to communication channel messages. While the information received across communication channels are adequate, the speed benefit to using the spell triggers (that you are receiving anyway) can not be ignored.
Below, I raise question if a spell registry or a private channel interface should be part of a comprehensive shared spell cast communication channel library. I cannot answer this question until I first know what the impact is of 25-40 people sending every spell/action they do across a raid channel. How much network lag/communications lag does it cause? This I cannot answer without running a rather massive test with cooperative people.

Discussion:

Question: Should STARTS/DELAYS/STOPS be sent across communication channels (as opposed to just broadcasting spellTarget from sent)?
Answer: For the case of future proofing, yes.
Advantages: Future Proofing
Currently the advantages to CastCommLib are being able to see spell casts at any distance and providing spellTarget information. Broadcasting all spell STARTS/DELAYS/STOPS future proofs it against possible events that could span an area greater than can be seen, although I can think of only a handful spells where this actually comes in useful currently: Resurrection, Ritual Summoning and Mind Vision.
Disadvantages:Ping times
People with high ping will not send their spell cast information quickly. STARTS, STOPS, INTERRUPTIONS, DELAYS will all be subject to other people's ping times. The sad part is such delays are avoidable, as all of this information can be gleaned directly from the server, so long as they are in range.

Follow-up Question: Should UNIT_SPELLCAST_ trigger events for units other than just the "player", like START/STOP/DELAY/UPDATE/STOP, be utilized?
Answer: Yes, as such information can be used in addition to communication channels
Advantages:Reduced Lag
Spell cast updates will be subject to your ping time only. This information can be used to supplement communications channel information.
Disadvantages:Asynchronous Complexity
The problem becomes an asynchronous one. How do you know when a unit is no longer in sight, and that you should use a message received from a communication channel message. This is a complex problem, but I believe it to be an ultimately solvable one.

Question: Should Spell Registration be part of CastCommLib as it was originally part of SpellSyncLib?
Answer: Maybe.
Advantages:Less Channel Spam
If addons were to register only the spells they were interested in receiving/broadcasting, then less channel spam would be necessary.
Disadvantages:Inter-Addon Compatibility
Broadcasting only spells an addon is interested in reduces inter-addon compatibility UNLESS the CastCommLib Develops a way to share which spells it is interested in with other CastCommLib clients.
It comes down to what you believe the library's purpose is: 1) The library's purpose is to provide anyone who has the library installed with information on any spell cast by anyone else with the library installed -or- 2) The library's purpose is to reduce channel spam by sharing a communication method and sending only the information each addon needs to see.

Follow-up Question: If channel spam is enough to warrant a spell registry, should addons be allowed to also designate a private channel to communicate over?
Answer: Maybe.
Advantages:Less Channel Spam
Only players that would need the information would receive it.
Disadvantages:Further Inter-Addon Combatibility
Addons that didn't know about the channel wouldn't be able to share in that information without it again/instead being broadcast across a channel the addon does know about. A solution to this issue is to have a multi-channel approach. If two different addons want the same spell information, but one wants it over a private channel, default to broadcasting it over raid/party if the casters are all in the same group. If there is a caster not in the same group/raid, broadcast it over both raid/party and the private channel.



The reason I have made such a careful analysis of this library is because I am considering making a next generation Spell Bar tracker; one where you would be able to track any set of spells bars being cast on any name/unitid (player, target, focus, party#, raid#, partypet#, raidpet#, mouseover) and see them in spell bar format. Like Healsync/Dorjae's Healing Bars/Forcast, only for any unit and any set of spells.