I got into a chat at the Ajax Experience about the side effects of COMET-style development on the web.
Currently developing COMET apps is tough due to the server side of the equation. Solutions are coming here though, and we will have COMET servers that will grok the new model, which is an event driven architecture.
If we take this further, I could see a world in which I build my web applications as a set of events rather than just thinking of request/response (which is limited events).
This will fit perfectly into many worlds:
- The Collaboration Web: publishers and subscribers are first class citizens, so it makes it trivial to create collaborative applications vs now when it is complex
- Web services / SOA: I am finding that my web “sites” are now compositions of services that talk to eachother or to the end user. Events flow through the entire process, and the “user” is just someone who can take part in the events
- Caching: I am a big fan of caching. From Tangosol Coherence, to memcached (man I would love Coherence for Rails…. I don’t believe in using the DB as heavily as DHH and co). A lot of the applications that I am working on currently are typical web apps in that they are heavy on reads. My caching system is based on events pumping in, and listeners take care of invalidating and filling up the cache when appropriate (caching in memory and html fragment caching). Even this low level world fits in with the event driven web
Dave Sifry talked about how the web wasn’t a library of pages, but rather a sea of events. How will the tools change, and our architectures to work with this?
Will we cling on to simple request/response because we know it, and it is simple (until you want to do something else….)?