| Sure. -- The 'request' module -- is mixing concerns (network protocol, caching, serialization, model) that you probably don't want to mix that way in a real app. It's pretty trivial to roll the polling part yourself (setTimeout), if you really need a plugin then PeriodicalUpdater[1] might be a candidate (although there are many others, and the cool kids use comet/websocket now anyways). I didn't quite understand the purpose of the caching part; the browser already caches for us after all. It seems like a misnomer for some sort of bridge to the localstorage, but I didn't quite get in what situation storing the verbatim server response would be useful - as opposed to storing the deserialized result (or part thereof). Anyways for the serialization part JSON2.js[2] is your friend.
And for models there are various choices, backbone.js[3] being the most popular recently. -- The 'store' module -- doesn't seem to provide anything interesting over jq-store[4]. And if you really want your data to stick around then there's evercookie[5] -- The 'pubsub' module -- was a little hard for me to understand the purpose of.
Since it isn't actually about server messaging(?) but rather only a way of passing events inside the browser it seems like what you'd really want is either JavascriptMVC[6], Backbone[3], perhaps knockout[7], or the older chain.js[8], or maybe one of the other two dozen data binding plugins. Admittedly on this last one I may very well just be missing the point entirely. PubSub inside the browser? Huh? [1] https://github.com/RobertFischer/JQuery-PeriodicalUpdater
[2] https://github.com/douglascrockford/JSON-js
[3] http://documentcloud.github.com/backbone/
[4] http://medialize.github.com/jQuery-store/
[5] http://samy.pl/evercookie/
[6] http://www.javascriptmvc.com/
[7] http://knockoutjs.com/
[8] http://ajaxian.com/archives/chainjs-jquery-data-binding-service
|