Huh?
In the same place I have error logging, I can have "Fetch URL" and send my self an SMS, or an email, or a fax, probably if I found the service a Carrier pigeon. Did my traffic fall off because someone else died? I can ask every 10 seconds "how many instances am I running?" and again fetch something from anywhere to send the message I need to the outside world. If all of Google went up in a pile of smoke. Then I might need something to check that I'm still running. and that would have to be external to GAE. Your long winded message basically says, I've been doing this for 20 years I'm an old fogey looking for a reason to be relevant, and the only fault I can find is that if something happens I want messaging. It's there enable it/build it/grow a pair. GAE is a platform you can do anything in the platform the platform has the bits to do. You can't build it to send you pictures of the blinky lights on the front of the server because it doesn't have a web cam, but short of that, anything digital, you just talk bits over the web to what you need to make the functionality happen. I want GAE to focus on Speed, and Reliability (and price [today more than ever :-)] ) not worry about is there JMS. You can bolt that on with the parts that are there. You're being a troll, or an attention seeker, or a combination there of. I need more APIs like I need a third rectum. And the APIs I do need are related to the things people "expect" from python and java. Which Google now calls "Backend" which they just announced TADA!!! They did the right thing. Not what the Analyst said to do, because it would seem he doesn't have experience with the platform. You are a Prius driver complaining that the Ferrari doesn't have a Continuous Variable Transmission, and that the Ford F350 doesn't have remote trunk unlock on the key fob. From: google-appengine@googlegroups.com [mailto:google-appengine@googlegroups.com] On Behalf Of Ray M Sent: Tuesday, May 10, 2011 12:05 PM To: google-appengine@googlegroups.com Subject: [google-appengine] Google should want to provide messaging in App Engine As an analyst with 20 years of object-oriented experience, 10 in web and Java technologies, who has worked exclusively with Fortune 200 companies for the last 13 years, I must implore Google to reconsider providing messaging to their App Engine customers. I think Google is the greatest thing to happen to businesses since the 7-layer OSI networking model, but in recent months I've discouraged clients from moving to App Engine because most of their enterprise business logic is triggered by JMS messaging, even from the web interface. It allows seamless integration with automated and manual workflows, such as "People A,B and C want to be notified when X happens and don't trigger Y until B approves" and the like. I implore the community of App Engine users, developers and customers to assist me in presenting an undeniable business case to Google. As such, I have begun with points from my own experience and analysis: 1. Because of its power and flexibility, messaging has become a critical component of automated inter-business communication. App Engine cannot compete fully in the business hosting sector without a messaging mechanism; and Google has the opportunity to create an implementation which makes all others obsolete. 2. Messaging implementations like JMS already inter-operate seamlessly with other languages. There is no reason Google must implement the server portion in Java or any particular language, and once implemented, can easily be made available to all App Engine hosting environments. 3. Most message-triggered business-logic need no response or just an ACKNOWLEDGE response, saving processing and bandwidth. 4. Multiple-destination deliveries can use UDP, saving bandwidth. 5. It will be a no-brainer for messaging to respect and contribute to engine quotas. 6. Message-processing listeners can be instantiated on demand, shuffled-around, load-balanced, cached and discarded just like servlets and can be included in the web app, or more efficiently deployed, operated and managed in its own name-based mass virtual-hosting environment with far less overhead than an entire servlet engine. 7. The world expects HTTP and HTTPS to be on ports 80 and 443, respectively, but not so for messaging! The implementation can provide a factory for client connections allowing Google to more effectively manage ports on the servers which act as entry points and frees Google from being able to use only DNS-based load balancing mechanisms on its entry-point servers. 8. Google, which is already quite adept at hosting, indexing and providing analytics for the world's standardized representations of information, will be in a stronger position to host, index and provide analytics for the world's disparate mechanisms of communication as well, or even to unify them. and, lastly, you have an intelligent and eager volunteer ready to sign a confidentiality statement and help Google's App Engine offerings to make all others obsolete! -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en. -- You received this message because you are subscribed to the Google Groups "Google App Engine" group. To post to this group, send email to google-appengine@googlegroups.com. To unsubscribe from this group, send email to google-appengine+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-appengine?hl=en.
