Hey all,
My situation is that I have a client app that uses XMPP to
communicate with other client apps using a MUC service. This works
well, is efficient and doesn't require much more than basic XMPP
support. When I heard that GAE had XMPP support I thought "hooray!"
but looking into it, it seems that what is meant by this is client-
side support, not server side. Yes, there is server-side support as
far as basic infrastructure, but beyond message transport, there is
nothing. In other words, you can write a bot, but you can't manage
accounts, access or anything like that. At least as far as I can tell.
I would like to avoid the situation where my users have to sign up for
an additional service, so I'd like this to be as automated as
possible. Right now, nothing actually requires them to create an
account on my system, or google.
Is there some way to get the functionality I am missing? It is
possible for all my clients to use the same JID as far as my system is
concerned, but I need too make sure that a malicious user can't do
something like go in and change the password, which would be
catastrophic, obviously.
Many thanks!
As a side note and comment for feedback, I think the XMPP bot
architecture is totally broken. You are forcing bots to be
asynchronous, and messages are converted into HTML-like call
structure, as if each XMPP message were independent and stateless,
like HTML! I know you can put data in the store and make this work,
and, of course, in some abstract realm this is valid, but XMPP is not
like HTML. HTML is usually about transferring state or data, or, in
some contexts, performing some action. XMPP, though it can server that
purpose, is often best thought of as a conversation, and a
conversation has a flow and has context. By using the stateless
interface, unless I am missing something, you really make that
difficult. Really, you are sending the message to developers: "you
might as well use html for your bots". Really: with this
implementation, you are saying, XMPP and HTML are the same, and sure
you have a few extra bells and whistles, but philosophically, this is
HTML over XMPP - you are making it hard for developers to leverage the
real strength and power of XMPP.
I realize that this implementation makes it easy to manage quotas and
so on, but there has to be another way, and I have some suggestions,
but I imagine you can come up with some things on your own. Imagine
trying to implement a handshake or other simple conversation like
this. No thank you!
bjorn
-----------------------------
Bjorn Roche
XO Audio, LLC
Audio Software & Digital Audio Consulting
http://www.xoaudio.com
http://blog.bjornroche.com
--
You received this message because you are subscribed to the Google Groups "Google
App Engine" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine?hl=en.
