npalmer wrote:
How is the current beta of this plugin working out for everybody that’‘s using it? We currently have a Wildfire + pymsn + pyaim setup here and I’'m looking to switch. The security features are exactly what we need ( the word is from the chat today that they are functional )
Well, first of all I would suggest looking over the issue tracker issues and deciding if any of those look like showstoppers to you. Yahoo is the most petulant right now. MSN is running pretty solidly and AIM/ICQ are running pretty well aside from missing some functionality (like the ability to delete people from your contact list). I switched from the Pys to the plugin on my own server about 2 months ago and it’‘s been running quite smooth for me. That said, it’‘s easy for me to track down bugs that -I- run into. Far less easy for me to track down bugs that others run into that I can’‘t reproduce. =( Now, there is one thing you could do to try it out, and this is what some folk did a while ago with PyAIMt and PyICQt when I first started putting out releases of those. Basically they set up the Pys as alternate JIDs and asked folk who were interested to try them out, telling them about the improvements and caveats and such. You can do that with the IM gateway plugin via the system properties found at the bottom of this page. Note the subdomain properties. If you set those to, say, aim2, icq2, yahoo2, etc etc, then you will refrain from conflicting with your current Py installs. I would recommend setting those -before- you enable the transports. =) I’‘d rather not speak on the stability in any definitive manner because really, I’‘m never going to run into all of the issues others do. I feel it’'s best to hear this from others who are using the software. =)
Also, if at some point you decide that you want to make the IM Gateway plugin be primary, the registrations themselves are tied to the transport -type-, not the name. So if you changed the subdomain of the AIM transport, all of it’‘s associated information would come with it. -however-, the JIDs of the transports themselves, as they existed in the users rosters, would not auto-change. (I just created an issue to consider a way to do this: GATE-150) This would not effect Spark as Spark doesn’‘t put the transports in folk’'s rosters (anymore at least). You could actually get around this with some quick and dirty direct modifications of the jiveRoster table. Basically if you were changing from aim2.my.server to aim.my.server, you could:
DELETE FROM jiveRoster WHERE jid LIKE “%@aim.my.server”
UPDATE jiveRoster SET jid = “aim.my.server” WHERE jid = “aim2.my.server”
This is effectively what I may implement in GATE-150 after I think through it some more.
We have problems sometimes with our python transports but I definitely don’‘t want it to get worse if we switched over to this plugin. It seems that we can’'t easily switch back and forth between them. Or is that not true?
This is fairly correct. The biggest thing is, the plugin will wipe all of the icq/aim/etc contacts from your real roster, depending on which transport the user registers with. (ie, if they register with the aim transport, all of the pyaimt contacts will be wiped) This will cause some confusion if you switch back to PyAIMt because PyAIMt will think you already have a lot of contacts in your roster, and will never request that you add them back. The way to get around this is basically to wipe your PyAIMt rosters (<spooldir>) from wherever you store them. Of course that means everyone will have to reregister and be re-bombarded with subscription requests. =/