Went down to Gold Coast with Chad and Zee today to see a client – a car sales agency, as a matter of fact. Young, chinese guy, smartly dressed. He had some pretty clear, not exactly in depth, but straight to the point requirements: See this (future rival) car auction website here, with its real-time bidding features? Now, build me one. In PHP, chop chop.
Ok, I kid… not quite the exact words, but you get the gist. Logically, I should comment on said rival website a bit. It boasts a pretty sound design: access the bidding page, and it loads a Java applet seamlessly, draws a simple textbox and a Big Red Button ('Bid’), rotating carousel of car photos, and generic auction details. Bids show up in textbox while they occur, it is linked to offline auctioning as well, and you click on the Big Red Button to add $200 to current going price. I’m guessing notifications are done either with sockets or dispatching HTTP calls, but judging by the speed of activity updates at times I’m betting sockets. I forgot to check what language the server would be on. I’m guessing PHP. So, let’s reverse figure out the design:
Applet (on the client’s Java VM) creates socket, server maintains an in-memory collections of connected ('subscribed’) clients, sends data stream down socket, applet read()'s, updates.
Not too complicated, but in the age of APIs, Rails-killer frameworks and Web-2.0-ness, perhaps dwelling a little too low-level on the client side. Still understandable, I suppose even though everyone thinks applet’s are sooo 1995, there’s still a certain supply and demand chain of Web 1.0 developers going on. Second mistake: no mention that the page uses Java – the client casually but specifically mentions the fact that he ingeniously figured out it needed the JVM. That’s one point off portability, and another off usability – and no, while Java is inherently cross-platform, the browser plugins are horrible on lower-end machines. Why else did the applets trend blow over and people migrate to Web Start? (See Wikipedia’s take)
Now this is where Comet (wiki) seems to fit perfectly. So it was quoth:
Comet is a programming technique that enables web servers to send data to the client without having any need for the client to request it. It allows creation of event-driven web applications which are hosted in the browser.
To explain further, instead of the “pull” paradigm in traditional HTTP
apps where you query the server for a response, the server keeps clients updated by somehow “push“ing notifications of events to clients. (Some wavy hand motions through the air usually help to speed up comprehension.) Think Meebo
and chat on Gmail. Recommended reading: HTTP streaming
, push technology
. Ok, perfect. Now implementing is the hard part, because simply reading a bunch of articles on Ajaxian last year doesn’t count, so some research is in place…
To tally current implementations,
- One notification-based implementation is in PHP, but it really just is a socket-server-client prototype.
- Most immediately-available (?) engines either directly implement the server (as a HTTP daemon or middleware app – I spot ICE!) itself, use J2EE, or a second medium for managing communications (e.g. Flash).
Now, the problems,
- The client insists on PHP (which, none of the three of us have mastered).
- I believe he uses shared hosting, on Apache.
- Note that there doesn’t seem to be any directly pluggable libraries like the J2EE WARs to support Bayeux...
- And since installing custom Apache modules to extend and implement efficient streaming is likely out of the question…
- And Comet may require certain implementation shifts on the server side to work properly (e.g. not closing HTTP sockets prematurely)...
- And from the Cometd mailing lists and other Googled sites, Apache (or at least, the fork version; I’m not sure if this is what his hoster uses) seems to be notoriously bad in terms of scaling. Keeping 1000’s of persistant connections open = need high efficiency.
- And finally, though it’s none of my business, I do worry about his quota and server hoster… Don’t they used to ban high-traffic generating software like CGI chat?
Hmm, dai pinch? Quick ideas,
- Scrap Comet. Poll server with Ajax calls every x seconds (where x is between 0.1 and 1).
- Scrap high-level stuff. Implement PHP sockets with PEAR library, and optionally use Java on client-side. Unlikely to work on shared hosting, isn’t it?
- We haven’t asked for more in-depth details. Ask if possible to use mod_jvm. Highly unlikely though.
- Scrap PHP. Move the whole darn site to Ruby on Rails! (We were joking over the RailsEnvy videos after the meetup)