Hi,
You could go with ii), but doing the filtering on the Lightstreamer-Server side, not on the client side.
There are several mechanisms on Lightstreamer to filter a data flow. For example:
- You can allocate a
maximum bandwidth to each user. The bandwidth can be changed in real-time (
see this demo ). How the data is filtered depends on the subscription mode and on the allocated buffer size.
- You can allocate a
maximum update frequency to each item/user. The maximum frequency can be set only at subscription time. So, to change it, you should unsubscribe and resubscribe from/to that item. These operations are very fast on Lightstreamer (so also option i) could work well). Again, how filtering works depends on subscription mode and its related parameters.
- You can set a
Selector in the Metadata Adapter to decide for each individual event for each user whether to filter it or not. The client specifies the selector at subscription time. To change it without unsusbcribing, it could simply send a message to the Metadata Adapter at any time. Notice that selectors are recommended only if the total throughout (data flow multiplied by the number of users) is not too high, otherwise this could be too heavy.
Consider that some of these features may not be present is all the
editions of Lightstreamer.
If you already have two feeds and you just want to switch between them, without imposing other intermediate filtering frequencies, I suggest you to try with i) first and see if the result is acceptable. A trick to reduce thrashing is to only fire the actual unsubscription/subscription only when the user releases the slider.
In any case, to have an idea of how fast it is to unsubscription and subscription,
check out this other demo.
