Reputation: 9691
Well I understand the basic functioning of ICEPush: The client subscribes, the server notifies subscribers when there is new data and then the client requests the payload through ajax. This works well enough, but there is a performance issue that arises on certain scenarios.
Suppose that I have a page that is tracking changes to several items. I subscribe to an ICEPush event on the server called "ItemChange", for example. This "ItemChange" event triggers every time that a process on the server changes an "Item" entity. Now suppose that a user is tracking items with ids 2 and 3, and then an event occurs on the server that changes item with id 5. The server will then notify an "ItemChange" event, which will make the client request a payload that is not useful to it, since it is not tracking item 5. This scenario would cause a lot of unnecessary calls to the server.
I've been looking for a way to circumvent this, but I haven't found anything yet. If I could send a parameter along with the notification, I could simply pass the id's of the item's that changed, and thus the client would know if it needs to request the payload or not, but there doesn't seem to be a way to do this. Any suggestions are welcome, thanks.
Upvotes: 0
Views: 152
Reputation: 229
Typically the best approach is to use multiple PUSHIDs. Are you using this with ICEfaces? How many items per page do you expect? Is there any natural grouping to the items?
Upvotes: 0