A bunch of general Comet questions
Simon Willison
I'm doing an introductory Comet talk in a few days. I plan to give a
pretty high level overview along with a couple of demos, but I'd like
to make sure that I'm up to date on the latest advances in the field.
If anyone can provide answers to the following questions I'd be really
grateful.
1. There's an obvious need to be able to send messages to a Bayeaux
server from something that isn't a connected browser (a tradtional PHP
server-side application for example). Is that what the "Unconnected
operation" part of the spec is for? Are there any client libraries for
this yet (preferably in PHP or Python)?
2. Is there any consensus yet on a way of controlling who has
permission to send messages to which channel? I really like the idea
that a Bayeaux server can be deployed without writing any code - it
would be nice if there was a simple configuration file that could be
used to say "only clients authenticated in this way can send messages
to this channel" - especially in conjunction with the aforementioned
API for sending messages from a regular PHP script.
I saw somewhere that Jetty (the server I'm currently experimenting
with) includes support for this, but I haven't found documentation or
examples everywhere.
3. Is "Bayeaux server" the correct terminology or should I be saying
"Cometd server"? My assumption is that "Cometd" refers only to
"official" implementations that are linked from the homepage of
http://cometd.com/
4. Comet techniques: Here's what I understand about them:
- The two principle techniques are "long polling" (where the HTTP
connection essentially stalls until an event occurs, at which point
the client instantly reconnects) and "forever frame" (where
incremental rendering hacks are used to send down script elements).
- The two-connection limit, combined with the general need for Comet
to run against a different server technology from regular server-side
scripts, makes it extremely advantageous to serve Comet events on a
different domain or subdomain - while taking in to account the 2
connection limit. Here's where I'm unclear: is it possible to do this
with both long polling and forever frame? For forever frame I
understand that the iframe fragment hack is used to communicate
between domains; does long polling require a similar workaround? I've
seen mention of a JSON-P style workaround - is that for forever frame
or long polling?
- How does XMLHttpRequest fit in to Comet? I assume it is used for
long polling - is there a cross-domain workaround that is normally
used when doing Comet with XHR?
- I notice that Opera now supports the WhatWG's server sent event
specification [1] - do Bayeaux or any of the Cometd implementations
take advantage of this yet? Are there any similar technologies for
other browsers?
[1] - http://my.opera.com/WebApplications/blog/show.dml/438711
I know this is a pretty big list of questions but I'd be hugely
grateful if anyone can provide answers. I'll be sure to write up
detailed notes and donate them back to the Comet community.
Thanks,
Simon Willison
Geoffrey Lee
Jason P
> 1. There's an obvious need to be able to send messages to a Bayeaux
> server from something that isn't a connected browser (a tradtional PHP
> server-side application for example). Is that what the "Unconnected
> operation" part of the spec is for? Are there any client libraries for
> this yet (preferably in PHP or Python)?
>
unconnected operation) it is fairly straightforward in PHP
Heres how you could post a message to the /chat/demo channel.
It requires the Curl and JSON (pecl) extensions
<?php
/*
Generic Object creation shortcut
*/
function object() { return ((object) NULL); }
// Create the Request
$request = object();
$request->channel = "/chat/demo";
$request->data = object();
$request->data->user = "Server";
$request->data->chat = "Info from server";
// The json encoding in PHP differs from other implementations it
encodes the '/' in /chat/demo as "\/chat\/demo"
// The ereg_replace removes the extra escaping. otherwise it gets to
the server as \\\/chat\\\/demo which results in an invalid or unknown
channel.
$vars = "message=" . ereg_replace("[\/]/", "/" ,
json_encode($request));
// Use curl to "POST" it
$ch = curl_init();
// Obviously your url will differ
curl_setopt($ch,CURLOPT_URL,"http://somehost/bayeux/cometd.php");
curl_setopt($ch,CURLOPT_POST,1);
curl_setopt($ch,CURLOPT_POSTFIELDS,$vars);
// If you dont want the response change this line to curl_exec($ch);
echo curl_exec($ch);
curl_close($ch);
?>
> 2. Is there any consensus yet on a way of controlling who has
> permission to send messages to which channel? I really like the idea
> that a Bayeaux server can be deployed without writing any code - it
> would be nice if there was a simple configuration file that could be
> used to say "only clients authenticated in this way can send messages
> to this channel" - especially in conjunction with the aforementioned
> API for sending messages from a regular PHP script.
stays out of authentication methods. Any additional requirements for
auth will always go in the ext part of a request/response. So to use
above example, if your server supported an username/password for
publishing your request could look something like this
$request = object();
$request->channel = "/chat/demo";
$request->data = object();
$request->data->user = "Server";
$request->data->chat = "Info from server";
$request->ext = object();
$request->ext->auth = object();
$request->ext->auth->username = "someuser";
$request->ext->auth->password = "password";
The way I control Authentication in the PHP cometd server I am writing
is by an object with a publish_auth method that takes the request as a
parameter, each channel can have its own instance of the object with
its own authentication method. or you could overide the default
behavior for all channels ( without their own custom method ) by
overiding the default objects method.
A very simple example of my publish_auth method with the request
above as the parameter would be
function publish_auth($request)
{
if ($request->ext->auth->username == "someuser" && $request->ext-
>auth->password == "password")
{
return true;
} else {
return false;
}
}
Bruno Tikami
I know some people have already asked this sort of question on this list but I haven't found any answer for it. So, can someone please write a simple tutorial about how to use de cometd-twisted server and the dojo client ? I've really tried to put it to work but never got it.
Thanks in advance,
Bruno Tikami
Greg Wilkins
I think many of your questions have been answered, but I'll
try to fills some gaps.
Simon Willison wrote:
> Hello all,
>
> I'm doing an introductory Comet talk in a few days. I plan to give a
> pretty high level overview along with a couple of demos, but I'd like
> to make sure that I'm up to date on the latest advances in the field.
> If anyone can provide answers to the following questions I'd be really
> grateful.
>
> 1. There's an obvious need to be able to send messages to a Bayeaux
> server from something that isn't a connected browser (a tradtional PHP
> server-side application for example). Is that what the "Unconnected
> operation" part of the spec is for? Are there any client libraries for
> this yet (preferably in PHP or Python)?
Well there is a bayeux client implemented in java so you can
send from another java JVM.
Unconnected operation is for 1 off messages from any bayeux client.
Note that non-bayeux protocols are probably better for sending
messages that do not go over HTTP. Eg nodes in a cluster can
use JMS for messaging and that can be bridged to bayeux for the
last mile to the clients.
> 2. Is there any consensus yet on a way of controlling who has
> permission to send messages to which channel? I really like the idea
> that a Bayeaux server can be deployed without writing any code - it
> would be nice if there was a simple configuration file that could be
> used to say "only clients authenticated in this way can send messages
> to this channel" - especially in conjunction with the aforementioned
> API for sending messages from a regular PHP script.
>
> I saw somewhere that Jetty (the server I'm currently experimenting
> with) includes support for this, but I haven't found documentation or
> examples everywhere.
Jetty has pluggable security policy and it would be easy to control
that from a config file.
But at this stage, there is little "standardization" on the server
side - specially as we span languages. However some unified approach
would be desirable as the project solidifies.
> 3. Is "Bayeaux server" the correct terminology or should I be saying
> "Cometd server"? My assumption is that "Cometd" refers only to
> "official" implementations that are linked from the homepage of
> http://cometd.com/
Bayeux server is the generic term for any server implementing the
bayeux protocol.
Cometd server is a bayeux server from the cometd project at the dojo
foundation.
> 4. Comet techniques: Here's what I understand about them:
>
> - The two principle techniques are "long polling" (where the HTTP
> connection essentially stalls until an event occurs, at which point
> the client instantly reconnects) and "forever frame" (where
> incremental rendering hacks are used to send down script elements).
And there are variations of both.
For example we handle pure json long polling and js callback (jsonp)
xd long polling.
> - The two-connection limit, combined with the general need for Comet
> to run against a different server technology from regular server-side
> scripts, makes it extremely advantageous to serve Comet events on a
> different domain or subdomain - while taking in to account the 2
> connection limit. Here's where I'm unclear: is it possible to do this
> with both long polling and forever frame? For forever frame I
> understand that the iframe fragment hack is used to communicate
> between domains; does long polling require a similar workaround? I've
> seen mention of a JSON-P style workaround - is that for forever frame
> or long polling?
Multi domains can only help a little bit.
the general solution is to share a single cometd instance - hopefully
between frames and eventualy tabs and windows.
> - How does XMLHttpRequest fit in to Comet? I assume it is used for
> long polling - is there a cross-domain workaround that is normally
> used when doing Comet with XHR?
XHR is hidden by comet. It may be used by some transport and not used
by some others.
XHR should not be directly used (or even used as a wrapper) by app
developers.
> - I notice that Opera now supports the WhatWG's server sent event
> specification [1] - do Bayeaux or any of the Cometd implementations
> take advantage of this yet? Are there any similar technologies for
> other browsers?
No. If there is the slightest hint that other browsers are considering
this, then we will look at supporting it.
> [1] - http://my.opera.com/WebApplications/blog/show.dml/438711
>
> I know this is a pretty big list of questions but I'd be hugely
> grateful if anyone can provide answers. I'll be sure to write up
> detailed notes and donate them back to the Comet community.
We'll hold you to this :-)
cheers
> Thanks,
>
> Simon Willison
>
> >