Ordering of updates about bokeh HOT 7 CLOSED

So I believe the problems come from backbones results of a server sync - the default behavior of backbone is to return the model as the server sees it after the sync operation, and backbone.js uses those values in place of the clients values. when we're updating very quickly, like during an interactive selection, latency can cause problems here. I'm not sure what the right solution is here - either versioning the model and ignoring older versions, or ignoring what the server gives us

from bokeh.

This is a fundamental problem with how we use Backbone, then. Perhaps we should have two "layers" of Backbone objects: one for client-only state and getting events among client side objects, and then "reflected" objects which will sync with server state.

My hunch is that trying to do this by only having one layer of objects on the client side, and then "hacking in" rate limiters, client side update loops, caching old versions, etc. is only going to lead to weirdness, corner cases, and fragility. Worse, those sorts of problems will be hard to reproduce because they will result from timing issues and updates and cache invalidations. If we have two explicit layers of objects, or if we give every object an ability to explicitly control its sync/reflection to the server, then we can at least have control over what happens during user interactivity.

from bokeh.

We don't call Backbone.save on every Backbone.set - but we do call save for the data source selection because we want that to be shared amongst multiple clients. I believe that's where the problem is occuring? Backbone assumes that the server will return you the truth after you try to save to the server, and that you re-sync on the client when the message comes back.

from bokeh.

On Mar 28, 2013, at 1:06 PM, pzwang [email protected] wrote:

This is a fundamental problem with how we use Backbone, then. Perhaps we should have two "layers" of Backbone objects: one for client-only state and getting events among client side objects, and then "reflected" objects which will sync with server state.

I very much agree.

My hunch is that trying to do this by only having one layer of objects on the client side, and then "hacking in" rate limiters, client side update loops, caching old versions, etc. is only going to lead to weirdness, corner cases, and fragility. Worse, those sorts of problems will be hard to reproduce because they will result from timing issues and updates and cache invalidations. If we have two explicit layers of objects, or if we give every object an ability to explicitly control its sync/reflection to the server, then we can at least have control over what happens during user interactivity.

We should have more defined interactions too. i.e. ServerUpdate 23 was the result of ClientData 20. If we are now at ClientData 30, we can have additional semantics for whether or not to apply ServerUpdate 23. In some cases it is relevant, in others not.

More defined semantics also include allowing javascript functions to perform transformations just as the server did. This could actually be a great way to use WebWorkers to offload computational complexity for some js operations ( imagine an FFT running in the browser in a separate thread).

—
Reply to this email directly or view it on GitHub.

from bokeh.

We don't call Backbone.save on every Backbone.set - but we do call save for the data source selection because we want that to be shared amongst multiple clients.

I think for the selector tool, the easy answer is to not set a data selection that is visible to the server until the mouse button goes up. If we really want to go wild, we can think about doing a "client side" selection and triggering "view model selection" as a different thing than "data model selection" (with the latter only triggered on selection finalization). The views/plots which can do realtime view update can choose to tie in to the client side selection event; even the ones which can't, can use this to show some "gray" or "invalidated" or "stale" state.

from bokeh.

@paddymul @pzwang is there any action to take on this?

from bokeh.

Closing, please re-open (or create a new issue) if there is some action to take.

from bokeh.