COMET on AOLSERVER
Ham
I saw a recent post here about patServer and PHP.
It got me to wonder if anyone has explored or looked into using
AOLServer/TCL (http://www.aolserver.com/)
Thanks,
Hamilton
Hamilton Chua
> I've vowed never to write TCL again,
I hope I have not unearthed some terrible repressed memory that is better off
buried in the greater expanse of unconsciousness but since it's out, can you,
pray tell, why ? :-)
Best,
Hamilton
David Davis
David
Alex Russell
Vignette.
The language itself is an abomination, but the messes I've seen...oy.
Regards
--
Alex Russell
al...@sitepen.com A99F 8785 F491 D5FD 04D7 ACD9 4158 FFDF 2894 6876
al...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
Ham
> Are you volunteering your tcl skills? :)
>
I work with a company called Solution Grove
(http://www.solutiongrove.com).
Our primary market is the Education sector. We develope web
applications using
dotLRN and the OpenACS framework.
Our CEO attended a conference last week and one of the things the
people are
asking for is an open source "online collaborative environment" where
participants of a
class can interact, chat, view presentations, exchange files, and
engage in real
time discussions. A virtual classroom if you will.
People in our market space whom we've talked to have seen what we can
do with Ajax (check out our website) and they're asking for more :-)
To answer your question. Yes I would love to volunteer.
I think an implementation in AOLServer/TCL would be interesting
specially if we can leverage it to improve the on line learning
experience.
David Davis
Would this be a sponsored by your company or on your own?
David
On 9/6/06, Ham <hamilt...@gmail.com> wrote:
>
Hamilton Chua
> Would this be a sponsored by your company or on your own?
>
So I take it there is interest in an implementation in AOLServer / TCL.
David Davis
I'd also like to get everyone writing their cometd servers to
eventually work behind Perlbal.
We need to get you setup in svn, etc, but we need a signed ICLA.
I'll look for that and email you the link and where to fax it to.
David
Roberto Saccon
David Davis wrote:
> Sure. We want cometd to have many implementations.
>
I started on an Erlang implementation, but it's currently in my private
svn.
> I'd also like to get everyone writing their cometd servers to
> eventually work behind Perlbal.
What do you mean by that ???
Hamilton Chua
> eventually work behind Perlbal.
Are you referring to this Perlbal ?
http://www.danga.com/perlbal/
In the OpenACS/AOLserver world I think many might recommend
http://www.apsis.ch/pound/.
Matt Goodall
From my brief experience with Pound I like it a lot, but it's probably
not a good choice as a cometd proxy: Pound is multithreaded, Perbal is
event-driven.
A busy site that uses cometd could easily have thousands of
simultaneous, long-lived connections. That's quite likely to bring a
threaded server to its knees.
Event-driven servers can typically handle many, many, many more
simultaneous connections with modest memory requirements and no
overhead of the thread context switching.
Perbal isn't the only event-driven server choice. A few more that I
know of are Twisted, Cherokee (soon to have an HTTP reverse proxy) and
lighttpd. I'm sure there are many, many more.
- Matt
Jason Lai
> From my brief experience with Pound I like it a lot, but it's probably
> not a good choice as a cometd proxy: Pound is multithreaded, Perbal is
> event-driven.
>
> A busy site that uses cometd could easily have thousands of
> simultaneous, long-lived connections. That's quite likely to bring a
> threaded server to its knees.
>
> Event-driven servers can typically handle many, many, many more
> simultaneous connections with modest memory requirements and no
> overhead of the thread context switching.
>
> Perbal isn't the only event-driven server choice. A few more that I
> know of are Twisted, Cherokee (soon to have an HTTP reverse proxy) and
> lighttpd. I'm sure there are many, many more.
>
> - Matt
Right now, from what I can tell, the cometd implementations are tightly
integrated with their respective webservers and event frameworks. The
twisted version uses twisted.web2 and the twisted framework, and the
Perlbal version hooks into Perlbal and the POE event framework. Often
you need an event framework anyway given that your application needs to
scale too, although there's some exceptions.
The problem with this approach is that you need to write a module for
every webserver and event framework. So if your app is written using
POE, you need a Perlbal-POE cometd to run on Perlbal, a lighttpd-POE
cometd to run on lighttpd, cherokee-POE, etc. Same with twisted. You
could always use proxies and run multiple web servers, but I don't
think that's a good way of dealing with it.
I think FastCGI could be a solution to this. FastCGI has decent support
in lighttpd, apache, and at least some support in twisted. It's a
lightweight interface for webservers to delegate HTTP requests to
external processes. So for example, lighttpd gets a request, passes the
request to a PHP process, which handles the request and returns the
result. It's like CGI, but the application doesn't terminate after the
request is over; it then waits for the next request. The FastCGI
protocol is asynchronous and event-driven, although not all
implementations support async mode.
Twisted and POE both have FastCGI servers (the webserver is the
"client" in this case), although the Twisted FastCGI server is
synchronous and I haven't looked into the POE version. So the upshot is
that it reduces the cometd code to just the event framework interface
and removes the need for messy web server modules.
- Jason
Alex Russell
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "cometd-dev" group. To post to this group, send email to
> comet...@googlegroups.com To unsubscribe from this group, send
> email to cometd-dev-...@googlegroups.com For more options,
> visit this group at http://groups.google.com/group/cometd-dev
>
> Visit the cometd website at http://www.cometd.com/
> -~----------~----~----~----~------~----~------~--~---
Alex Russell
1.) as you note, most *users* of FastCGI spaw new processes on a
per-request basis. If each response is per-process, there's not much of
a reason to use it. If, OTOH, the system is written to multiplex
between a single process and the FCGI interface on an HTTP server that
isn't OS-threaded (aka, not apache), it could work well.
2.) we have an x-domain transport now, so you could run cometd on a high
port or on a different server and not have to integrate it into your
existing web tier at all. I think that removes most of the
configuration hairballs that we're both leery of.
3.) decoupling the event server from the network responder runs the risk
of making it "too easy" for people to put cometd into service with a
network responder that will fall over, at which point they need a new
network responder anyway. Moving to FastCGI might only be a win for the
RoR crowd who have already invested in a new responder.
Regards
David Davis
event server is currently being developed alongside the Perlbal
plugin, but isn't tightly coupled to it. The plugin could also be
used with any other event server that supports the bayeux protocol.
The event server, whichever language it may be written in, should keep
a single persistent connection to each perlbal server. There is no
forking in this configuration, and therefore saving cpu and memory.
A threading web server and a FastCGI server isn't an ideal system for comet.
David
David Davis
All event servers should be able to connect out to one or many Perlbal
servers and communicate with the bayeux protocol to relay events to
the right clients. In this setup, the client sockets are held by
Perlbal, the request is reproxied to the web app to authorize the
connection, and then Perlbal announces the connection to its connected
event server.
This allows the event server to do less work and to spread the high
number of connections across machines to scale horizontally. We'll
eventually have event servers that can peer to each other for
failovers.
-David
>
> >
>