perhaps i can frame your objection to Bayeux as a protocol a bit differently: by needing a compliant protocol server, Bayeux encourages interop, a proliferation of clients and servers, and allows anyone to layer behaviors like what you’re talking about (sending code to be executed) on top of an orthogonal protocol stack. Joe Walker and Greg Wilkins have alpha-level Bayeux support in DWR to achieve exactly this: let each level of the stack do what it’s best at and plug them together.

Instead of being one-off, tied to a particular implementation, and requiring you to build the app from the bottom up w/ Comet features in mind, Bayeux lets you put your Comet server in your infrastructure *after* the app it built/deployed….which basically means that railing against lower-level protocols like Bayeux just doesn’t even make sense. ItsNat does something one level up the stack…great! That doesn’t make Bayeux less valuable nor does it imply that they’re mutually exclusive (except for implementation decisions by the ItsNat team).

Regards

In ItsNat the COMET approach is amazingly simple, only a special Java method is called in the server, CometNotifier.notifiyClient(), and the server will send to the client any pending user defined JavaScript code to the client. This JavaScript code is executed “as is” in the client.

* open up a bi-directional tunnel with a Bayeux server. Once a connection is opened you can publish JSON messages to a named topic and subscribe to hear about messages that you (or other senders) publish to those topics you’re subscribed to
* subscribe a handler to a particular topic
* publish a JSON message to the topic. The serialization of the message into JSON and the wire-level details are all handled for you by the client library.

You send and receive pure JS objects, and it’s all JSON on the wire.