"Push" API

[Timothy Kaler]

It would be nice to have a single API which allows various parts of the application, and 3rd party extensions to be able to "Push" client side events to the user. These events might be notifications, updated content, or something else.

There could be a single poll to the server which fetches a list of JSON objects at some admin configurable frequency. Each JSON object should specify a javascript function and its arguments. Each object would represent an event that the application wishes to "push" to the user.

To decrease the cost of polling, you could associate each event with an auto-incrementing id. Then each client could locally store the last event id they received, and a server side file associated with the user could contain the last event id the application "pushed" to the user. Then there would be a static file associated with each active user on the board, and each user could make low cost polls to their static file to determine whether or not they need to make a more costly poll to the database utilizing event fetching script.

~Tim

 

[AlexandrosD]

Let's be positive they started using simple jQuery AJAX calls.
A real AJAX Push server like APE is required to do the things you mentioned, the proper way.
Let them, at least finish the core, before asking such extreme features.
Hopefully you didn't ask for periodical AJAX requests. That's nice...

~Alex

 

[Timothy Kaler]

Let's be positive they started using simple jQuery AJAX calls.
A real Comet server like APE is required to do the things you mentioned, the proper way.
Let them, at least finish the core, before asking such extreme features.
Hopefully you didn't ask for periodical AJAX requests. That's nice...

~Alex

I'm aware of the relevant technologies. I do not like the buzz-word "Comet" because it is not descriptive, and it does not actually refer to a specific implementation strategy.

Long http requests are not always the optimal way to give the illusion of "pushing" events to the user. Infrequent polling uses less server resources. Also, the implementation I mentioned is easily modified to use long http requests to provide "more instant" delivery of "pushed" events.

~Tim