- three new URLs are "exposed":
- /event/forward accepts events published on the client and publishes them on the server
- /event/bind send the information about which events the server would like to subscribe to to the client
- /event/listen is a comet connection which is used to transfer events published by the server to the client
- lib/bespinserv/pubsub.js implements the actual pubsub mechanism in the server.
- a java.util.concurrent.locks.ReentrantLock() is used to implement the lock for the comet implementation. This was taken and slightly modified from the ServerJS comet example.
- Whenever a subscription is fired on the server, the event queue (and thus the associated client) is saved in a global variable (remember JS is single threaded) so that when the server does a publish we know where to send the event.
- Multicast publishes are not supported.
- Upon "/event/bind" the client creates stub event subscriptions which forward the actual event to the server using /event/forward
- The client connects to /event/listen. Once it returns the client publishes the returned event and starts listening again immeditately.
I'm personally not convinced that this architecture should be used because the beauty of REST goes away. On the other hand, I feel that the artificial border between client and server does not make sense for some applications and thus it is great if it goes away. Opinions?