Dig this - network events into the browser... who'd a thunk it? (Other than the half dozen companies doing it over the past five years.)
Secondly, the browser isn't a good listener to external events. If you want to build an application, for example, to show you instantly when someone bids or a price changes, it is hard. You can poll, but poll too frequently and the application starts to feel sluggish and it isn't easy to do this. What you really want is an event driven model where in addition to the events like typing the page can describe events like an XMPP message or a VOIP request or a data-changed post for an ATOM feed.
1 comment:
Yes, I mean like KnowNow. I used to work there when they started in Seattle. I helped with discussions of server design and implemented javascript libraries and demo applications - things like soap serialization/deserialization in JScript, buy/sell auctions, AIM clones, etc. Lots of fun.
I'm not sure what you meant with "[...] should both update page two and show you visually that this happened".
When we were working the client-side of things, we eventually came to the conclusion that extending the markup language with trivial 'subcribe to foo and call this function' attributes on any element would be a simple and powerful way for developers to write apps. The WhatWG has recently defined exactly this kind of markup extension to HTML. See What WG and event-source The message protocol/format is in dire need of help, but it's a solid start.
It truly is amazing what you can do with this client application model, and using something like SEDA (staged event driven architecture) for the server, efficient server resource usage isn't so impossible either.
Post a Comment