Shared State between users

[emptyrivers]

Is your feature request related to a problem? Please describe.

There are a fair number of auras which have a dependency on something like AngryNotes or ERT to essentially replicate the raid leader's configuration to the raiders without having to go through the trouble of publishing new aura versions every time you adjust your strategy on a boss.

So my thinking is, since this is a thing our users do, why not support this in house?

Describe the solution you'd like

In the simplest possible implementation, an option somewhere which when enabled, asks you to select who the "source of truth" is for the state (by default, make it raid lead), and also provides a code box for user to write data into, akin to TSU custom variables.

WeakAuras would then, for each of these auras, disseminate the truth source's state to other group members, whose auras would then receive an event with the updated data.

Pros:

• we can support a broader swath of use cases that our users find.
• fewer addons to manage means greater dominance of WeakAuras users potentially have access to tools they wouldn't otherwise think to find
• fewer people would misuse custom option for custom behavior that a user isn't meant to modify unilaterally

Cons:

• redundant? how many people would bother to learn to use this when they already know how to use other notes addons
• performance? is this an undue burden on the addon message channel? perhaps we should discourage people from putting gigabytes of data into shared state?
• complexity? we would need to account for all the various ways that sync could be broken. Obviously if an addon message gets dropped there's not much we can do, but for it to be reliable we should probably look into how other similar addons ensure reliability?

[InfusOnWoW]

Yeah! We do have quite a few other examples that this is something that would be useful, e.g. Zen Tracker, but also Interrupt trackers. What makes those more complicated is that there is a need for everyone to communicate to everyone.

Now, where I think you are correct is that "state" is the right primitive for communication. That is often communication in distributed systems is often modeled as each participant sending events to each other.

But I doubt people would be able to write reliable software on top of that, due to the unpredictable order in which events might come in. With states, it's much more likely that people automatically write code that only depends on the state, and not in which order events came in.

When I think about that kind of feature, I think of it as the final frontier but maybe that's just how I think about it, and maybe there's some kernel of it that can be implemented.

The way I think about it, and I'm really talking about things that I normally don't even mention because they are that far outside of any reasonable timeline.

One my next features that I have already talked about is the visibility rewrite and the eventual deprecation of a lot of trigger checks. E.g. instead of having the trigger checking for "remaing <5s, or stacks > 2", that's a job for visibility checking. This gets rid of the "show" member in the state.

With that, many triggers essentially create duplicated states, which brings me to one of the further refactorings. The "state universe", that is many triggers don't need to create states, instead there's a tree of "potential" states in the state universe, e.g.

Spell Cooldowns
-> Execute
-> Slam

I do have some more thoughts on that, and lots of things that are complicating that picture. E.g. custom code (argh), buff trigger (argh^2) which complicate that picture.

And most triggers will just subscribe to these states. The states only track what they need to track if someone is subscribed. And crucially the triggers don't copy the data into their state, they simply refrence the state from the state universe.

(Note a lot of code in WA can actually be modeled as subscribers on states.)

Which then brings me back to your idea, I think that then fits the model perfectly as a "remote state tracking", so e.g.
subscribing to Remote/Group/Spell Cooldowns/Execute, automatically subscribes to Execute spells in your party/raid.

That then would translate for the "raid leader" aura, as the raiders get a simple aura that subscribes to Remote/raid1/custom/uid(?)/state. And the raid leader has a aura that publishes its state to the path /custom/uid(?)/

There are plenty of complex questions, but that's how I envision that area evolving.

Now to your cons my answer to them:

• Well yes this is a feature for very few peole, though it's a very cool one.
• I think if we send deltas of states, then the performance should be okay. The trick is to ensure that everyone in the system has the previous state, or asks for a full update if they receive a unmatched delta.
• I think SendAddonMessage is actually a pretty reliable primitive.

[emptyrivers]

ah, that's a good way to model the idea, though i don't think it's a prerequisite for this feature.

...we may actually want to build up the bones of such a state tracking system using custom shared state. might be a good playground to learn the pitfalls, and then later teach other trigger systems how to employ the same bones