We’re using a Google Apps for You Domain domain, and it provides GTalk chat client too (it it’s Gmail variant), but it always connects to Google’s servers, and not the ones specified in the DNS SRV records for my domain - an Openfire server of ours. We still would like to provide the gateway functionality of Openfire to our users (to access MSN, ICQ, etc. there) so I’m thinking if it is possible to use it as some kind of router that forwards IMs to Google’s servers (from any gatewayed network) if it sees a user of ours login to them. Do you think it’s possible with Openfire and your gateway or maybe some other software - and if not, do you think it will ever be implemented? Anyone else run into this problem?
I’m going to answer you here even though we started this conversation over email. (for the benefit of others)
First off, here was my first response:
Wow =) Ok, a couple of blanket statements first. The IM Gateway plugin explicitly only works with local accounts. (it uses openfire internals and therefore can’t work with external things without major reworkings and ejecting some of the “cleanness” about the implementation) PyAIMt, PyICQt, PyMSNt, PyYIMt, PyIRCt, PyXMPPt … all of them should work remotely. (like you can set up an openfire or whatever server somewhere and they can be used from GTalk)
That said, I’m afraid I don’t really know anything about forwarding IMs. You might be able to do something where you “tie” an openfire account to a gtalk account and somehow log in the openfire account with the gtalk account and forward messages … but that sounds kinda scarey. ;D
I don’t know if I’ll ever implement remote servers being able to connect to the plugin. It completely destroys any ability to be “smooth” about the whole process. Like on first registration you’d be back to getting a flood of “will you add me?” from each and every contact. There’s lots of room for things getting out of sync. It’s actually part of the reason why I adored creating a plugin based on internals. =/
Now to answer your followup:
Thanks for the answer! What do you mean by usable from GTalk. The
Google Talk client? That will only connect to Google’s servers. Or you
mean generally an XMPP client?
With the python based transports, they really don’t care where you are coming from. They follow XEP-0100 more or less dead on. So even if you are on google talk, you can register your google talk account with, say, aim.myserver.org. The IM gateway plugin can not do this because it uses mechanisms inside of Openfire to tie directly into your roster and such… which means it can’t tie into a roster on another server somewhere else which means it can’t really be used from an external server.
“Google Talk” the Win32 client app, and Gmail’s integrated chat client - the one we’d like our users to use - will only connect to Google’s servers, so registering my whoever@gmail.com with another server (which has Py… installed) does not help. It is really some kind of routing that we need. Or we can drop the whole ide, and give another chat client to our users, but…
I believe there have been a number of folk using PyAIMt and PyICQt from their google talk accounts. I have had reports filter in here and there. Google talk’s servers have s2s enabled like anything else and you can connect to them from non-google talk clients. Like one could use Psi, log into the google talk servers, use service discovery to connect to another server somewhere ruinning PyAIMt and such, and register remotely.
It’s not the account that is interesting, but the actual Gtalk chat client (built into Gmail - have you seen that?). You can’t use service discovery with that. It will only connect to google’s servers. What you say (using other clients) works fine, but that is not our problem. We’d like to provide Gmail+Gtalk (from Googla Apps for Your Domain) plus your gateways somehow. Do you get the difference?
Of course I get the difference but I don’t think we’re syncing up here. =) If you register from, say, Psi with a transport at aim.myserver.org, then log in with the real google talk client, it “just works”. aim.myserver.org is now a roster item on your roster like anything else, and receives presence when you log into your google talk account regardless of whether it’s the standalone client or the gmail+gtalk mini-app. All aim.myserver.org cares about is that it hears your presence as you come online.
The main drawback here is it requires an extra step … logging in from a different client than any of the gtalk ones first to register.
One could probably write up a little web interface to effectively perform the steps on the user’s behalf:
-
log into their gtalk account
-
register with aim.myserver.org from said gtalk account
-
handle the various “do you want to subscribe to this contact?” spew that comes forth
-
log out
Then the user could log in with a real gtalk client and be done with it. Would “just work”. Like I said before though, this does not work with the IM gateway plugin and would only work with other transport implementations. Unless you can figure out some magical way to tie together a local openfire account with a google talk account, the IM gateway plugin won’t be able to handle this. (at least not at present, possibly never)
Syncronization begins… I’ll try what you suggested. Thanks!
Good luck!!! If you don’t mind, let us know how it goes! =)
Slowly advancing…
http://www.bigblueball.com/forums/general-other-im-news/33739-connect-google-tal k-aim-msn-yahoo.html