![]() But that's assuming we have a generic way to apply the updates like I mentioned above, rather than dozens of event types needing custom code.Īlso I assume that there will be a source of truth here, a place clients connect to receive these updates (much bigger conversation if not). The dev work to support a protocol that exchanges this information is probably about similar to the dev work to implement partial run updates. needing full state seems over-engineered to me. The part about letting clients smartly tell you whether they're too dumb to update a run with partial information vs. Otherwise I would be very concerned about timers staying in sync if an event fails to process / implementation difference causes ripple effects in the run / etc. Plus clients won't need to know both how to read the state format and how to apply changes to it that come from events they just constantly display their current state and blindly apply updates to it using a generic patching library. That way we won't need to maintain both a format for state and a protocol for events (the "events" would be defined by the state format). If the Splits.io exchange format is in good shape (or if we can get it there), we can get a lot of this stuff for free with something like JSON Patch. The initial design is mostly for observing timers, but you may also be interested in controlling the timer, so that's something that is probably going to be part of the protocol eventually too. What may not be properly considered in this design are proxies, such as splits i/o that may not be "sufficiently smart clients", but need to serve the information back to clients that may be. Based on the client's ability of parsing the absolute snapshot, we either send some rough information or the full splits file. ![]() or we send an absolute snapshot of the current information again. Then either the client is smart enough to update its information about the PB, possible history, etc. The idea so far is that synchronizing a single attempt isn't too hard, we just need to update the times of individual splits until eventually the attempt is done. We absolutely need to design this together with the splits i/o people and need to do this really soon as they are beginning to diverge too far.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |