Congrats to Adam, Joyce, and the rest of the Renkoo team on the launch of their beta (beeta). I think George gives a decent one-line description of the service:
Renkoo is essentially Evite on crack; an efficient, featureful, real-time way to coordinate group events.
I haven't explored it very much yet, but it seems quite cool. I have never really liked Evite, but it's a useful service that many people I know use. Now I finally have something better to point them to when I complain as I'm accepting an invitation. :-)
The about page mentions being powered in part by these third parties:
Ben mentions their use of Comet, a new term that describes an old technology:
Comet applications can deliver data to the client at any time, not only in response to user input. The data is delivered over a single, previously-opened connection. This approach reduces the latency for data delivery significantly.
The Renkoo user interface is definitely feature-rich. I haven't explored it enough to see which features are a result of this technology, but it sounds like Comet is a lot like using flush() to send output to the browser before a page finishes processing. This is made possible by sending a chunked HTTP response, which is one that is broken into pieces. Instead of a Content-Length header designating the size of the response in its entirety, each chunk indicates its own size (in hexadecimal), with the final (empty) chunk being 0 bytes in length, so the end result looks something like this:
Content-Type: text/html; charset=UTF-8
<p>Friends, Romans, countrymen, lend me your ears;</p>
<p>I come to bury Caesar, not to praise him.</p>
I'm assuming this is what Comet refers to, so not only does it describe leaving an open TCP/IP connection, but in fact it describes a virtually never-ending response, where the browser is kept waiting for the next chunk. I'd love to hear George comment about what pitfalls this presents in terms of scalability. You know it has to present some challenges with all those open connections. :-)