IssueTracker

You don't need all that other behavior... just a "hanging get" would let you
implement the other stuff on top of it. I.e., let a http get request be serialized to
the database in some way, so some other process can pick that get back up and respond
to it.

But yeah comet in app engine would be great! There is already a third party offering
this service, which is yet more evidence that it's useful:
http://popcnt.org/2008/05/missing-services-for-google-app-engine.html

Yes indeed , this will be the most sought feature in google apps.
if not can you document the maximum processing time allowed for an request.
by this we can atleast start of with some alternatives.

Regards
Dave

I'm really hoping that this will be added together with the promised XMPP support...
That'd be the logical place for it.

Fingers crossed the Google guys realize that this has more value than "support Java" etc. in terms of facilitating
the development of really interesting applications...

I can't fully run my app without it.  Without comet type support (I prefer to use
DWR), I'll have to do a mashup and send requests to another server for processing there.

It'll be awkward to have the app and data on appengine but conversations (chats)
about the data going to another server and being pushed out from there.

ICEfaces can also make use of this feature, compare:

http://icefacesauction.appspot.com/

http://auctionMonitor.icefaces.org/

The demo is a lot more fun with Ajax Push.  This can be implemented with either Servlet 3.0 or (since the App
Engine is using Jetty) Jetty Continuations.

The jetty team would certainly be interested in working with google to make our
continuations available.

Even if behind the scenes they we implemented as a blocking wait/notify, this would
at least allow code to be deployed with the asynchronous semantic.  Google could then
do their own calculation if it is best to make this truly asynchronous or just throw
more memory/threads/machines at the problem.

Note that the continuation API in jetty-7 from http://eclipse.org/jetty has been
somewhat refined and the thrown exception has been removed.   This updated API is
intended to be a bridge to servlet 3.0 and applications written against it can be
deployed on any 2.5 or 3.0 servlet container, but will only be truly asynchronous
when running on jetty or a standard 3.0 container.
 

I really like this feature.
Server initiated rendering is very cool.

I vote Yes!

I would also love this feature. I'm looking to develop a multi-player AJAX game and
was seriously considering using appengine as the host, but due to the lack of
official comet that makes it near impossible. Still, I'll be watching this issue as
well as possible third party appengine comet support offerings.

I vote this too! Without comet support ,I have to remove refresh function of my app:
http://geo-twitter.appspot.com/ 

I too vote yes

If you'd like to see this implemented, star the issue, do not leave a comment. Every
time a "me too" comment is left, 153 emails get sent to people like me, which makes
my phone beep. Additionally it makes the ticket less readable :)

yes

[Comment deleted]

[Comment deleted]

this issue is discuss for so long. may i know will this feature be available for next
app engine release?

Can't wait for this feature to get it working with pubsubhubbub protocol.. I'll guess
that this feature becomes available when google launches the open beta for wave.
Anyway, xmpp is on the roadmap. I would like to hear some dates :)

ya. we all want to hear dates .hehe=)

m.e.siersema brings up an interesting point. To truly make Wave succeed, having wave protocol built into google
app engine would be a huge boost for wave development! Doing that would also fulfill at least in part, all the
comet type requests.

See http://docs.google.com/View?id=dg7nkx7d_3239mc4rs4g for a simple and secure proposed solution.

[Comment deleted]

Wouldn't generic support for CallHome allow users to instruct a web application to
make requests to any server they desire?  That doesn't sound like the best security to
me.

Isn't this the stuff you've been waiting for: http://pubsubhubbub.appspot.com ?

I see now what is wrong with pubsubhub... its a server-to-server protocol. still no long polling on GAE :(

Couldn't you add a client endpoint to a small app and have the publisher (via post) in the same app too?
Think "chat engine"?

Hey there,

Please remember that 262 people get e-mailed every time a comment is left on this
ticket, it causes phones to beep, including in the middle of the night, all over the
world. :)

In the absence of official comment from the AppEngine team on the status this
particular feature request, I think a much better forum for discussion of
alternatives would be the appengine groups themselves.

Thanks!

If I am to use an external comet server I already have many great open source options
(http://cometdaily.com/maturity.html), Orbited for example is brilliant.

The point is to be able to serve comet connections from within the GAE
infrastructure, thus taking advantage of Google's reliability, smart pricing model,
and auto scaling capabilities. It would also remove cross-domain scripting issues of
having separate comet and "regular" web servers.

I don't see comet capabilities being shoehorned onto the current GAE request cycle
because, from an engineering point of view, GAE is diametrically opposite to the
requisites of comet. It's designed to handle massive ammounts of short-lived http
requests, scaling automatically. To accomplish this no simple feat it has to
compromise on every aspect that makes comet possible today (most notably, the server
ability to hold an http request).

Google could and should, though, offer a separate but integrated comet server
companion to GAE. Bonus points if they used an open source solution like Orbited
(which is written in python BTW) that would not lock my apps into GAE.

Sorry in advance for the beeping phones ... :)

I clicked to support this issue a while back, the ticket itself was posted over a
year ago, there are over 250 developers supporting it, and still I have yet to see an
actual reaction from a google employee on this issue (apart from the label changes
and acknowledgement status).

So hi Google people! May we have some feedback on this?

Specifically:
- Has any decision been reached with respect to comet-type functionality?

If yes, and it's a go:
- Could you give us a rough idea on when we might expect a release?
- Do you have an overview on how your version of such functionality will look like?

If yes, and it's a no-go:
- Could you give us a short explanation why this is not going to happen for GAE?
- Is HTML 5 (event-source, Web Sockets) what we should wait for?
 
If no:
- No more questions, I'll try to be patient :) (and check alternatives, not including
cross-domain scripting)

Thanks for any reply, regards,
Sam

1. The CallHome Server solution only ever tells the the client to do its normal poll sooner. It can never make the
client call any URL other than the one it normally polls.
2. I agree that I'd like Google to provide a solution that is complimentary to GAE. I think a CallHome service is
the right and minimal way for them to do that. If done in the general way that I specify then it could also be used
by non-GAE apps. Then if it becomes popular it could migrate closer to the user. Actually it only needs to be
just outside the users firewall/NAT box, and it could easily be incorporated into that box [remember: doesn't
need to keep any state across reboots].
3. I'm trying to get up the energy to write an IETF InternetDraft, which I haven't done for 10 years.

Supposedly the XMPP support just released is the solution to this problem (issue 231). I haven't worked out how
to use it. How does the javascript on the web side of your application receive the sent XMPP message? Note that I
posted this question in issue 231 as well and I apologize to the people watching both issues.

XMPP support in GAE is not a solution to this problem. GAE doesn't provide an XMPP client for users of your app.
I'm still waiting for some information about when long-polling will be supported in some way by GAE.

Please Google give us some idea as to the way you see GAE used for real-time apps.

can anyone share what workaround that you folk doing right now? anyone doing "relay
to external" for comet in java?

Robert, can you eleborate how to run your demo callhome? it's in "C" ? only 1 file?

[Comment deleted]