I have installed OpenFire, and the IM Gateway plugin. I’ve activated AOL, MSN, and Yahoo. Using PSI I have created an account for my GTalk identity. What I want to do next is use the ‘service discovery’ option to register the transports for AOL, MSN, and Y! to my GTalk account, thus allowing me to see all my biddies via the GTalk desktop client.
However, I cannot see the transports in the service discovery dialog from my GTalk account in PSI. If I create an account on the OpenFire server and set it up in PSI, I can see all the enabled transports, register with them and see the biddies on those lists.
My question is, how do I allow my GTalk account in PSI to see the transports on my server? It appears to me that there is some setting in the server that is blocking visibility of the available transports.
Thanks in advance,
Mark
The thread you point me towards suggest that I need an account on the local server. I have an account created, and with that account I can see the IM transports I’ve enabled on the server. However, in order to combine AOL, MSN, and Y! into my GTalk account I need to perform the service discovery from the GTalk account. When I select the service discovery option from the GTalk account I cannot see my server.
I’ve tried adding the GTalk account name to the list of users on my server without any success. How do I expose the transports to service discovery?
Thanks
Mark
You can not use the im gateway plugin via remote servers, period. There’s no way to set up a local account that “matches up” with your gtalk account to make it all work. The im gateway plugin uses internals of openfire to keep everything in sync (roster wise and such) so it avoids the problems you face with external transports (like PyAIMt, which was also written by me). It is on my list to “consider” looking into a way to offer a “degraded” way to interact with an external xmpp service but right now that’s not possible. It’s hard to decide whether it’s a good idea to add that extra level of complexity because unfortunately the issues that come up result in a bad user experience, not a bad developer experience. =/ (in other words, the end user is who feels the pain of the remote service -> openfire -> im gateway plugin interaction … it’s not something that’s “just hard for me to implement”)
You -might- be interested in doing the other direction. Use a local account on openfire as your main account and use the GTalk transport to connect from that local account to your GTalk account, thereby pulling all of your contacts into one location.
Mark,
You cannot bind MSN, AIM, etc to your GTalk account until GTalk offer that service (which they probably wont because of the licensing issues).
The best bet you have is to use your local openfire installation, create a local account on that then connecting to that account from psi use service discovery to join to the networks you wish (Gtalk, AIM, MSN).
Then whenever you sign in with psi to your local openfire you’ll have an aggregated buddy list.
Mike
Since this topic is stating the question (and answer) more clearly I’ll just reply here…
GTalk already allows binding of AIM and MSN and other services through itself to another server. Right now I have my MSN and AIM account linked with my GTalk account (using hot-chilli.net as my gateway).
Would it be a difficult change to implement? I swear I’ve seen/used another public Openfire server to link with AIM from GTalk.
It’s not a limitation in the concept of transports. It’s a limitation in the IM Gateway plugin and it’s architecture. Any server running PyAIMt, PyICQt, PyMSNt, etc would be able to handle what you ask. (which is probably what those were running) The IM Gateway plugin ties heavily into the user’s session behind the scenes which is what prevents it from being used this way. Like I said earlier, I am -considering- adding such functionality at some point, but even if it do it’s not going to be a happy end user experience. =(
One of the nasty end user experience pieces of it is that if you, say, register with AIM, you have to actually accept subscriptions from every person in your contact list from AIM. Trivial if you have 3. Painful if you have 100. There’s not really good clean ways to handle “look, I’m a transport and these are your contacts, accept them in one batch and don’t fight me on it”. This is where the IM Gateway plugin shines because instead of bothering the use with such things, I edit their roster from inside of openfire and add the contacts so that they aren’t ever pained by requests to accept adds.
I’m actually thinking about doing a podcast to explain all of this because I think it would be fun. =)
Even if I do add it, it’s not something I can do “overnight”. Would require a fair amount of restructuring of my code.
Generally for this kind of functionality I recommend the Python based transports. (PyAIMt and friends) Of course they require setting up python and twisted on your server … which you may not be excited about doing. ;D
Can the py*t plugins actually work with Openfire or do I have to to ejabberd?
Oh definitely! They should work with any server implementation out there that I’m aware of! In fact that’s how I first got talking to the Jive folk was trying to work out some little issues I ran into witih PyAIMt and PyICQt’s interaction with openfire. =)
Any chance you can point me to a how-to? Google keeps bringing me back to IgnitionRealtime forums to other users posts who have the same issue (heh maybe I should’ve used the search before posting).
I actually have documentation up online for PyAIMt and PyICQt =) You should be able to apply similar stuff to PyMSNt. PyYIMt and PyIRCt are different in style but shouldn’t be too hard. Take a look at:
http://wiki.blathersource.org/wiki/index.php?title=PyAIMt
or even just wiki.blathersource.org ;D
Thanks! I’ll tackle all of it today and see where I get Thanks for the help and clarification about the IM Gateway. Hopefully the function gets added in a later release
jadestorm, I seem to be getting some errors when trying to run pyAIMt:
Traceback (most recent call last):
File “PyAIMt.py”, line 16, in <module>
main.main()
File “/home/ron/pyaimt/src/main.py”, line 449, in main
app = App()
File “/home/ron/pyaimt/src/main.py”, line 399, in init
twistd.checkPID(config.pid)
I asked around in #twisted and some people have said that pyAIMt is making calls which twisted doesn’t support/supports privately that third-party developers shouldn’t be using. Any ideas?
I would hop on the py-transports@blathersource.org list (www.blathersource.org) and see if anyone has any ideas there. I turned over development to others as I haven’t had time for it in a long time and at this point I’d say they have more experience dealing with twisted’s nut-job-ness =) (it’s always been a moving target to try to work with twisted =( )
I was hoping to be able to use OpenFire, and the transports plugin to register all my identities with GTalk so I could use that cleint on my laptop. Since I can’t discover the transports from the GTalk identity in PSI, there is no more need for me to have OpenFire. As for going the other way, I can use Pidgin as an all-in-one client without jumping through these hoops. However, its UI is nowhere near as pleasing to me as the GTalk UI.
Thanks to everyone who participated and provided thoughts and insights.
Mark
Lots of people seem to like Trillian and on Mac OS X there’s Adium X as well.
Trillian is a fine product, but one that charges money for access to the GTalk protocol. I do have a couple of Macintosh computers and make extensive use of Adium as an all-on-one client on that platform. I was hoping to be able to combine all the protocols I have presence on into GTalk. All I need is a jabber server I can install on my XP laptop, that I can then add the required transports to, and discover from inside PSI with my Google account.
Mark
Yeah that’s one of the big things that got me into XMPP in the first place (combining everything into one). Keep an eye out at ignite realtime, if you are interested, because I’m planning on doing a podcast to discuss the very issues you are running into. (in terms of why I don’t support it and pros and cons and that sort of thing) Hopefully it’ll be informative. Either way, sorry that this didn’t end up being a good solution for you!
Out of curiousity, if you are using Psi, why are you opposed to going the other direction? In other words, connect to your own Openfire server and have your account on that server connect to your Google account. My guess is it’s because you want to use the built-in chat interface in gmail and or google talk’s standalone client? (I’m a little surprised you can’t point the standalone at another xmpp server) To sort of maybe answer my own question, Psi isn’t really what you want to use, just use it to set things up?
A little hex editing of the GTalk client and you can change the server to anything you want Its what I did to keep using Openfire and yet be able to connect to my gateway plugin.