rdfs:comment
| - Potential applications of GuildComm:
* Making player talents, gearsets, tradeskills, etc. available to any guildie at all times
* Radically enhanced raid scheduling including players automatically storing their bound Raid IDs for continuation scheduling
* Adding personal scheduling information e.g. "I'm available to raid at these times, but going on vacation this weekend"
* Managing DKP/EPGP/etc. and other per-player data without multiple addons competing for the extremely limited officer-note field
* Addition of more guild info to Guild Bank, MotD, etc.
|
abstract
| - Potential applications of GuildComm:
* Making player talents, gearsets, tradeskills, etc. available to any guildie at all times
* Radically enhanced raid scheduling including players automatically storing their bound Raid IDs for continuation scheduling
* Adding personal scheduling information e.g. "I'm available to raid at these times, but going on vacation this weekend"
* Managing DKP/EPGP/etc. and other per-player data without multiple addons competing for the extremely limited officer-note field
* Addition of more guild info to Guild Bank, MotD, etc. Features of GuildComm: (to-be-implemented in parentheses)
* Automatic master election (attempts to assign the task to the most capable machine online at the time)
* Filesystem-style storage allows multiple addons to store and retrieve data in a manner that fits the addon
* Minimum-traffic peer-to-peer protocol uses folder signatures and timestamps to ensure everybody is kept up to date
* (Officer-level files are password-encrypted so all guildies help disseminate them but only officers can see them)
* (Special file types designed to accommodate multiple editors, e.g. officers tracking DKP and attendance, comments, etc.)
* Uses ChatThrottleLib for all communications, (with a big-message layer on top)
* Very simple API: File_Set(path,data), File_Get(path)
|