How to use OCW with a PHP application?
nvd_ai
I am trying to understand and use OCW to create some client-side
cooperative widgets. I have to build the Web site around client-side
application using PHP+Apache on the server and use Java-based OCW
(i.e., jetty) only for co-operation. Here I am facing a couple of
problems that I do not know how to solve:
1- In OCW demoes jetty handles both server-side handling of HTML pages
and co-operation tasks. What I need is to separate these two, give the
server-side handling of Web pages to PHP+Apache while using OCW as a
service that I include in my project and it adds co-operation support.
But I do not know how to do this. Any solution?
2- At the deployment level, I should create a new OCW application
using maven and copy all my own application into the src folder and
deploy it using mvn jetty:run-war. To me, this is less favorable to
move my whole application folder (which further affects the code
repository, etc.) to integrate OCW into my application. It would be
great if I could add the OCW into a directory under my application
folder (e.g., myApp/lib/OCW) and include a single (or two) JavaScript
files in my application to access the OCW service. I then can run
jetty to take care of co-operation and run the rest of application on
Apache. But I am missing the right solution in here. Any Idea?
I think there already exists a right deployment solution to address
these problems. Would it be possible for you to give me some clues?
cheers,
Navid
Brian
The best way to handle this would be with a reverse proxy. For
example you could run a coweb server on 8080 within jetty, apache /
php running on 9090, and a proxy server like nginx running on 80.
nginx defaults all traffic to apache on 9090 while redirecting /admin,
and /cometd to <server>:8080/admin and <server>:8080/cometd.
The only issue with this approach is that if you wish to secure your
application your going to have to come up with your own credential
sharing mechanism between apache and your coweb server.
Regards,
Brian Burns
nvd_ai
I have a questions following your answer. Would it remove the need for
a proxy server if I switch from Java to Python for the server? I
checked the OCW documentation again. On the Python APIs section there
is a 'Application Containers' section there is a part that talks about
Apache shortly. There is a 'httpStaticPath' parameter that can be set
to 'None' to handle only session traffic. This is not described in the
Java API section. But based on what you mentioned it seems like the
same is possible with Java. However, I think it would make my life
easier to not to use a proxy server and leave all the work to Apache.
Would this be possible with the Python server?
Best,
Navid
Peter Parente
The limitation here is the same origin policy enforced by the browser.
The long-polling transport cometd uses by default uses XHR to
send/recv messages to and from the coweb server. XHR can only contact
a server under the same domain as the web app. The proxy hides this
problem by making the web app (PHP in your case) and the coweb server
(Java or Python) appear to come from the same domain.
The Java implementation of CometD supports callback-polling, however,
which should work cross-domain. We've never tested it, but it may just
work. Also, CometD supports WebSockets which do allow cross-domain
connections with the right set of headers. We've currently disabled
websocket as a transport in coweb though because the spec is in flux
and not implemented uniformly across browsers.
Pete
--
Pete
nvd_ai
I can test the Java CometD and report if it works cross-domain. But I
don't know where to start. Can you give me some instructions to start
with?
Basides, you mentioned that the websocket has been disabled. Is it
still part of the code that can be enabled, configured, and tested in
different browsers?
Does not Dojo.WebSocket solve the cross-browser issues?
regards,
Navid
Peter Parente
> Thanks Peter for pointing out the problem.
>
> I can test the Java CometD and report if it works cross-domain. But I
> don't know where to start. Can you give me some instructions to start
> with?
Actually, I realized after sending the mail that you'd fail contacting
the admin REST API across domains, so, no, it won't work without
improving that request to use CORS or something else.
> Basides, you mentioned that the websocket has been disabled. Is it
> still part of the code that can be enabled, configured, and tested in
> different browsers?
> Does not Dojo.WebSocket solve the cross-browser issues?
It's commented out in cometd.js. We can (should) make
enabling/disabling it a configuration option in cowebConfig.
dojo.io uses WebSocket if it's available, but it doesn't solve that
WebSocket is at different implementation levels in different browsers
(http://en.wikipedia.org/wiki/WebSockets#Browsers_supporting_WebSocket).
Your server has to speak the same version WebSocket protocol as the
browser. Besides, 1) Dojo isn't a dependency for OCW and 2) cometd
does select fallbacks for missing WebSocket support (i.e.,
long-polling like it's doing right now.)
> regards,
> Navid
>
>> The Java implementation of CometD supports callback-polling, however,
>> which should work cross-domain. We've never tested it, but it may just
>> work. Also, CometD supports WebSockets which do allow cross-domain
>> connections with the right set of headers. We've currently disabled
>> websocket as a transport in coweb though because the spec is in flux
>> and not implemented uniformly across browsers.
>>
>> Pete
>>
--
Pete
nvd_ai
Please correct me if I am wrong and add if something is missing.
The options are:
1- Using a reverse proxy like nginx. This seems to be the most do-able
solution, though I think it has some drawback including those typical
drawbacks of a reverse proxy. Besides the fact that it increases the
deployment and server maintenance complexity, does it introduce
performance issues? OCW is all about real-time applications. We do not
want to lose all the beauty of OT by adding non-necessary technology
layers. I have no experience with reverse proxies. Anyone has some
experience with this?
2- WebSockets is still not there yet. I guess we have to wait some
time till the standard is stablished. So, it is not an option yet...
3- Using other cross-domain solutions require setting CORS attributes
on the server. To me this is like lowering the security on the server
side. Am I right? otherwise, setting some properties on the server
seems less painful than option 1 to setup and maintain a reverse
proxy. What are the trade-offs in here?
Are there any other solution that I am missing?
regards,
Navid
On Apr 14, 12:30 pm, Peter Parente <pare...@gmail.com> wrote: