Javascript Client Server Question

[martin]

I'm using the dojo cometd 1.3.2 library and having a working protoype
that subscribes to a channel from Oracle Complex Event Processing
(uses the BEA Weblogic cometd implementation). I have a simple static
web page and my a javascript code in separate file that renders a dojo
graph and updates the graph each time new messages are received over
the comted connection.

However, I can only get this to work if the web page and Javascript
are served up by the same web server that is publishing the channel.

Let me elaborate a little more.
In my javascript I use the following to subscribe :
var cometURL = "http://localhost:9002/pubsub";

cometd.init(cometURL);

cometd.subscribe("/pubsubchannel", "onMessage");

And in my browser I open the following URL :
http://localhost:9002/carpark/newdashboard.html

If I deploy the web page and Javascript to a different web host the
onMessage function never gets called. I receive no errors and no data
at all.

If I keep the web page and javascript on the same server put point the
cometd.init(...) to identical code running on a different Oracle CEP
server the onMessage function never gets called and again I receive no
errors.

In a production ready deployment I would want to deploy the web
application to a different server to the CEP server in a three tier
style. Is this possible?

[Simone Bordet]

Hi,

When the cometd client is initialized with a URL that does not point
to the origin it has been downloaded from, you have a cross-domain
communication.
The latest Cometd client (1.0.beta10) supports cross-domain
communication via JSONP; the current trunk also supports the
cross-origin specification.
The latest Cometd server also supports the JSONP transport and current
trunk also supports the cross-origin specification; I am not sure what
the Oracle CEP supports.
If the server does not support cross-domain communication in a proper
way, then you may have troubles.
This can only be discerned by Firebug logs of Wireshark logs. Can you
post those ?

Simon
--
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless. Victoria Livschitz

[Luis Montes]

How does the cometd server know what the JSONP callback function name parameter is?  Is it something that dojo & comet have just agreed upon?  Can it be specified if it doesn't match?

Thanks,

Luis

[Simone Bordet]

Hi,

On Thu, Sep 24, 2009 at 21:14, Luis Montes <mont...@gmail.com> wrote:
> How does the cometd server know what the JSONP callback function name
> parameter is?  Is it something that dojo & comet have just agreed upon?  Can
> it be specified if it doesn't match?

The client sends the callback name to the server. This is part of the
JSONP "hack".

Cheers,

[Luis Montes]

Right.  I was just wondering what keeps that parameter name synched up between what org.cometd.server.continuation.ContinuationCometdServlet expects and the parameter passed to it by dojox.cometd.init()

Dojo's JSONP implementation dynamically names the actual function that should be called, but it has to let the servlet know the parameter name the function is set to.

For example, twitter uses a callback parameter name of "callback".   I'm sure dojo & cometd will stay consistent with the whatever they chose for the parameter name, but is it currently overrideable on the client and server?

Luis

[Simone Bordet]

Hi,

On Thu, Sep 24, 2009 at 21:37, Luis Montes <mont...@gmail.com> wrote:
> Right.  I was just wondering what keeps that parameter name synched up
> between what org.cometd.server.continuation.ContinuationCometdServlet
> expects and the parameter passed to it by dojox.cometd.init()
>
> Dojo's JSONP implementation dynamically names the actual function that
> should be called, but it has to let the servlet know the parameter name the
> function is set to.
>
> For example, twitter uses a callback parameter name of "callback".   I'm
> sure dojo & cometd will stay consistent with the whatever they chose for the
> parameter name, but is it currently overrideable on the client and server?

dojo.io.script.get() accepts a parameter called "callbackParamName"
which we set to "jsonp" (hardcoding it in the cometd JS
implementation), while ContinuationCometdServlet uses a hardcoded
"jsonp" parameter name.
So the client has to send "jsonp" as a parameter name (not value!) for
the ContinuationCometdServlet to work.