Comet is not really brand-new (Ajax) term today; however, with most of people how it works remains somewhat mysterious.

I have a little hand-on experience with Comet when creating a hobby game project with DWR Reverse Ajax sometime ago. It (DWR) was simple to start and really worked but required a Java web server (Tomcat, Jetty…) that I found rather expensive (in term of resources) for such small application. I want a small, dedicated and reliable server for Comet apps while don’t like to be deeply sunk in technical terms like “Bayeux” or “Continuation”.

After reviewing the Comet Maturity Guide from Comet Daily I decided to give Meteor Comet server a try for several reasons, especially because it’s built on Perl that can be easily deployed in any server with Perl installed (i.e. almost all Linux servers, no?) and it should be lightweight (up to my experience with Perl). Here is other info about Meteor server:

1. Server daemon will run on any platform for which Perl is available.
2. In live use typically 1,000 clients per node receiving 2 msgs (~400 bytes) per sec each. Tested up to 5,000 clients per node receiving 1 msg/sec each.
3. Nodes exist independently, supports broadcasting for message distribution. Cluster of three Meteor nodes runs FT Alphaville.
4. Transports are completely configurable within simple constraints.
5. Server supports client ‘catch-up’, allowing clients to regulate quality of service themselves.
6. Stable, in production use.
7. GPL v2. Free.

Install & Setup Meteor Server

You can find very good how-to guide for installing Meteor server from Meteorserver.org; actually it’s quite simple to follow. Just download, extract to default location (/usr/local/meteor) and configure daemon service as guided. One notice is on Fedora/Cent OS the start function in init scripts must be changed from:

Read the rest of this entry »

If you are web developer you may have noticed that the latest version of Yahoo’s User Interface toolset and widgets (for web development), YUI 3.0, is now available as a preview release. YUI has long been a popular “Ajax” library both because of its liberal BSD license, and because of the number of features it provides.

The big news about YUI the third are that it changes from the root and (unfortunately) is not compatible with YUI 2.x APIs as Eric and Matt stated on developer blog.

YUI 3.0 builds off of the YUI 2.x codeline, but we’ve evolved most of the core APIs in working toward the five key goals described above. As a result, migrating from YUI 2.x to 3.x will require effort at the implementation level.

However, YUI 3.0 will ship with a limited compatibility layer for the current YUI Core that will allow you to run some of your YUI 2.x-based implementations (Yahoo Global Object, Dom Collection, and Event Utility) on top of YUI 3.0.

These radical changes are toward 5 goals:

• Lighter (less K-weight on the wire and on the page for most uses)
• faster (fewer http requests, less code to write and compile, more efficient code)
• more consistent (common naming, event signatures, and widget APIs throughout the library)
• more powerful (do more with less implementation code)
• more securable (safer and easier to expose to multiple developers working in the same environment; easier to run under systems like Caja or ADsafe)

Read the rest of this entry »