The team at Weelya announced v1.0 of the Open source APE JavaScript Framework & APE Server, their comet-based push engine created to ease the client/server communication.

New features in APE 1.0:

• New and improved communication protocol :
  • Entirely using JSON and fully extensible.
  • Several commands can be nested in one request.
• New transport methods :
  • XHRStreaming : A single connection is used to send and receive data. Better performance
    and reduced transfer delays.
  • JSONP : Allows to place «cross-domain» requests.
• Support for BSD & Mac OS X (running the APE server) implemented by using KQueue
• ServerSide JavaScript (SSJS) Implemented by using TraceMonkey (Mozilla SpiderMonkey)
• Mootools support on the server side.
• Complete Server-Side JavaScript API:
• • Handling of users, RAWs, Commands, Channels, Sockets
  • Use of non-blocking sockets (Client & Server)
  • MySQL connector module
  • API for doing external HTTP requests
  • WebHooks
• Log files for errors, access and general information

They've also created an online comic book to get you familiar with what APE is all about.

Even PHP developers can write web applications that use all sorts of fancy long-polling.

That is what Leo said about his NGiNX HTTP push module:

This module turns Nginx into an adept HTTP Push and Comet server. It takes care of all the connection juggling, and exposes a simple interface to broadcast messages to clients via plain old HTTP requests. This lets you write live-updating asynchronous web applications as easily as their old-school classic counterparts, since your code does not need to manage requests with delayed responses.

NHPM fully implements the Basic HTTP Push Relay Protocol, a no-frills publisher/subscriber protocol centered on uniquely identifiable channels. It it an order of magnitude simpler and more basic than similar protocols (such as Bayeux). However, this basic functionality together with the flexibility of the server configuration make it possible to reformulate most HTTP Push use cases in Basic HTTP Push Relay Protocol language with very little application- and client-side programming overhead.

Configure NGiNX and write some code to talk to it.

The following is a guest post. If you have something to say to the Ajaxian community, please feel free to either link us to your work, or give us a guest posting that goes into detail! Contact us.

My name is Jerod Venema, and I'm excited to write to you about our new Comet server for the Microsoft stack - WebSync. It is written in 100% managed C#, and uses IIS to reach incredibly high user concurrency. Despite being written in C#, we've made it easy to integrate other languages as well by pre-building client libraries and allowing generic HTTP requests to send messages.

There are many challenges in getting a Comet server to operate efficiently in any language, and the .NET environment delivers its own set of unique challenges. One of the biggest challenges we faced was how to make IIS "play nice" when scaling to tens of thousands of concurrent HTTP connections and message transactions. A great deal of time was spent minimizing the memory footprint (even to the point of lazy object construction), optimizing libraries, and digging through pages of profiler results. Multi-threading reared its ugly (but powerful) head on more than one occasion as we sought to take maximum advantage of multiple CPU cores while keeping locking and concurrency issues to a minimum. We even ended up writing a new lock-free data structure similar to a linked queue that allows us to perform multiple-writer add/remove operations - very helpful when dealing with large lists of clients and messages. Once all was said and done, we tested on a $500 Acer desktop and saw over 30,000 concurrent users and 25,000 messages per second. (We were pretty pumped when we saw some of those numbers coming through!)

Once we were satisfied with the server's performance, we set our sights on a JavaScript client. We had originally been using the Dojo Toolkit, but the overhead was more than what we wanted (it rang in at about 90k after compression, but before gzipping), so we wrote our own library that, when compressed and gzipped, comes across the wire at about 8k total (just over 15k before gzipping). We also ran into a slew of cross-browser issues (of course), in particular when dealing with long-lived HTTP connections. A bit of effort, though, and we can now claim the client to be fully compatible with over a dozen browsers, from IE5.5 all the way to the iPhone and Android browsers. Being fans of open-source technology (even in a Microsoft world), we decided to use the Bayeux transport protocol rather than develop our own, so any Bayeux-compliant client can link in to the server.

We also spent some time on making it easy to integrate into non-browser applications. One of the really neat features is the ability to publish data via a simple GET/POST request, so it can integrate into any application that can make a web request, regardless of the language. If you're writing in PHP or .NET, we've made life even easier by writing publishers that wrap up the creation and invocation of the web request into single method calls.

Oh, and we've got a hosted version too (WebSync On-Demand), so people with smaller sites who don't want the cost of hosting their own Comet server can still get all the benefits of a full Comet solution. For the On-Demand solution we've also implemented request proxing, which allows developers to direct the low-impact publish and subscribe requests to their server first, so they can pre-process any incoming messages (to add authentication, save messages to a database, etc). And again, for PHP or .NET users, it's a one-liner to implement.

Anyway, it's a pretty neat product, easy to get started with, and as I said, we're pretty excited and proud of it, so check it out including demos or tutorials and let us know what you think!