You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should "upstream" the History flight module because it is probably useful outside of noexc flights and also makes it easier to document how to set up mapview-websocket in a sensible way (i.e., most implementations will probably want historic data sent to new websocket connections and right now that is a manual process for all implementations. Moving this to mapview would turn that into "Add a callback to your MapviewConfig and add a callback to where you initialize the websocket server" and everything else would "just work".
The only issue is that this assumes a sensible ToJSON instance for the parsed packet type (I have a document started on what "sensible" means here -- we'll have to provide a specification at least for our own frontend; of course other frontends could require different things). If other frontends require different formats and we want to be able to use all of them at once, then that is an issue, but I think we should worry about that later on. We already have this issue after noexc/mapview@a660e33 anyway.
(The usual solution here is to newtype but then we couldn't use the normal callbacks in MapviewConfig anymore because the newtyped types would no longer match our t).
The text was updated successfully, but these errors were encountered:
We should "upstream" the
History
flight module because it is probably useful outside of noexc flights and also makes it easier to document how to set upmapview-websocket
in a sensible way (i.e., most implementations will probably want historic data sent to new websocket connections and right now that is a manual process for all implementations. Moving this tomapview
would turn that into "Add a callback to yourMapviewConfig
and add a callback to where you initialize the websocket server" and everything else would "just work".The only issue is that this assumes a sensible
ToJSON
instance for the parsed packet type (I have a document started on what "sensible" means here -- we'll have to provide a specification at least for our own frontend; of course other frontends could require different things). If other frontends require different formats and we want to be able to use all of them at once, then that is an issue, but I think we should worry about that later on. We already have this issue after noexc/mapview@a660e33 anyway.(The usual solution here is to
newtype
but then we couldn't use the normal callbacks inMapviewConfig
anymore because thenewtype
d types would no longer match ourt
).The text was updated successfully, but these errors were encountered: