Comet + Cherrypy Tutorial using orbited

Hi there,

On 6/12/07, Michael Carter <cartermichaelgmail.com> wrote:
> Hello,
>
> I have just finished a tutorial on writing comet
applications for CherryPy3,
> though the basic concepts will work fine with CherryPy2
as well. Comet is
> simply sending asynchronous events from the server to
the browser. It is
> used by Gmail's chat application, for instance.
>
> The tutorial can be found here:
> htt
p://brbx.com/orbited/tutorials/cherrychat.html
>
> This tutorial is part of the orbited project which is a
python daemon to
> make comet easy.
>
> I would appreciate feedback on the tutorial. Any
problems or thoughts are
> welcome.

Thank you Michael for a good tutorial. Straight to the
point.

The tutorial seems more of a CherryPy tutorial for people
that know
Orbit - and not vice versa though. For example:

"If you recall our orbit.cfg file for this
tutorial"

I didn't find any reference to the orbit.cfg file anywhere.
Also, if
you could add a short explanation of why you use the tuple
(user,
cherrypy session, "/ajax") as a key - and how that
key is used to
match outgoing events to connected users.

I'm also missing an explanation of who/what handles the
"/cherrychat"
location. Seems the iframe doesn't specify a different host
or a port
- so is CherryPy handling that URL and forwarding it somehow
to Orbit?
Or does the Orbit stuff run in the same process as
CherryPy?

Anyways, this looks an interesting project. It so happens
that I'm
just planning a project that will use comet heavily and I
was planning
to do it with Twisted alone. I'll certainly consider this an
option.

Some "I haven't rtfm" questions:

Does Orbit support two way message passing, i.e. can the web
browser
use it to pass events to the server? I know one can just use
XHRs, but
I'm just curious.

You use the iframe transport method, what other methods are
supported?
Does it have any special provisions for communicating with
Flash/Flex/Apollo apps?

When you send events via orbit.simple.Client.event(...) - is
it the
responsibility of the sender to list all the receivers of
the event?
Can I send events to all connected users without tracking
them myself?

thanks,
Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/cherrypy-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi there,

On 6/12/07, Michael Carter <cartermichaelgmail.com> wrote:
> > I didn't find any reference to the orbit.cfg file
anywhere.
>
> Good catch here, the reference to orbit.cfg is missing.
I put it in and i
> believe it will help answer some other questions of
yours as well.

Ah, yes. Those five lines made the pieces fit 

> The orbited daemon runs in a separate process. The
conclusion mentions that
> instead of dealing with cross-domain scripting issues,
the cherrychat
> tutorial simply uses the orbited proxy to skirt the
issue. This is also made
> more clear in the new orbit.cfg explanation.

Yes, indeed.

> > You use the iframe transport method, what other
methods are supported?
> > Does it have any special provisions for
communicating with
> > Flash/Flex/Apollo apps?
>
> orbit ships with XHR and iframe transports. Its
actually pretty
> straightforward to add a transport, and in fact
flash/flex is pretty high on
> the priorty list. I'm not sure what the state of
python/flex is, but I
> wouldn't 'want to reinvent a library to parse flex
stuff. Assuming that
> exists though, it would take about an hour to add and
test flex as a
> transport.

There's flashtickle by Bob Ippolito (http://undefined.org/pyt
hon/) and
DjangoAMF (http://djangoamf.sourceforge.jp/index.php?DjangoAMF_en
).

The latter looks more complete as far as AMF goes. I had to
tweak it a
little bit to get AMF3 to work, that is being able to read
it's own
output. I haven't tried talking to a flash/flex app though.

However, Bob is with Mochi Media and Flash apps is their
business.

> > When you send events via
orbit.simple.Client.event(...) - is it the
> > responsibility of the sender to list all the
receivers of the event?
> > Can I send events to all connected users without
tracking them myself?
>
> the orbited daemon plays a pretty simple role so that
it can be distributed
> across multiple nodes that have no knowledge of each
other. Therefore its
> the sender's responsibility to keep track of the
receivers. There is a
> bayeux implementation in the works that will run on top
of the orbited
> daemon and do just that -- keep track of channel
subscriptions for event
> publication. Alternatively you could use the already
existing cometd
> project, though the documentation for cometd is
complete nonexistent.

What is the difference between orbited and cometd, i.e. what
does (or
will) orbited do that cometd doesn't?

Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/cherrypy-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi there,

On 6/17/07, Ionel Maries Cristian <ionel.mcgmail.com> wrote:
> what issues does a threaded approach raise?

Threads are by nature expensive. The memory useage of a
pthreads
thread is usually about 1-2 mb.

The premise of using threads for a webserver is that
requests are
handled fairly quickly each (measured in milliseconds). You
keep a
thread pool of several dozen threads (depending on your
load) and only
keep a reference to a thread for the duration of the
request

Comet uses long-running connections however. There can be
many seconds
and even minutes between the time the connection is made
until the
response is sent. In the meantime, a threaded server keeps a
thread
checked out for that duration without using it.

If you have on average 1000 connected users, this means you
need to
have 1000 threads just for the comet stuff - plus threads to
server
the regular requests. That's 1-2 GB of memory that goes
largely
unused.

Another factor is that context-switching between threads is
expensive.
Not as expensive as context switching processes - but you
need to
switch out the whole calling stack every time. Threads that
do little
or no work are thus inefficient because they only waste time
switching
back and forth.

Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/cherrypy-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Jun 17, 3:11 pm, "Arnar Birgisson"
<arna...gmail.com> wrote:
> Hi there,
>
> On 6/17/07, Ionel Maries Cristian <ionel...gmail.com> wrote:
>
> > what issues does a threaded approach raise?
>
> Threads are by nature expensive. The memory useage of a
pthreads
> thread is usually about 1-2 mb.
>
> The premise of using threads for a webserver is that
requests are
> handled fairly quickly each (measured in milliseconds).
You keep a
> thread pool of several dozen threads (depending on your
load) and only
> keep a reference to a thread for the duration of the
request
>
> Comet uses long-running connections however. There can
be many seconds
> and even minutes between the time the connection is
made until the
> response is sent. In the meantime, a threaded server
keeps a thread
> checked out for that duration without using it.
>
> If you have on average 1000 connected users, this means
you need to
> have 1000 threads just for the comet stuff - plus
threads to server
> the regular requests. That's 1-2 GB of memory that goes
largely
> unused.
>
> Another factor is that context-switching between
threads is expensive.
> Not as expensive as context switching processes - but
you need to
> switch out the whole calling stack every time. Threads
that do little
> or no work are thus inefficient because they only waste
time switching
> back and forth.
>
> Arnar

i wasn't referring to a threaded approach to the comet
communication,
but the cherrypy thread pool, sice you usualy have multiple
requests
comming at a given moment and 1 thread would give some
latency if that
1 cp thread isn't fast enough


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the
Google Groups "cherrypy-users" group.
To post to this group, send email to cherrypy-usersgooglegroups.com
To unsubscribe from this group, send email to
cherrypy-users-unsubscribegooglegroups.com
For more options, visit this group at h
ttp://groups.google.com/group/cherrypy-users?hl=en
-~----------~----~----~----~------~----~------~--~---