Hi folk! Something changed in the minimum client version requirements for MSN over the past couple of days and as a result, I am putting out a new version of the plugin to compensate. That said, the new version accounts for quite a bit more than just the MSN fix. There have been quite a few bug fixes and improvements that can be read about in the change log, but I wanted to touch on one in particular. Before I get into that, you can, as always, download the new version of the plugin here.
The new feature I wanted to touch on is that SIP/SIMPLE support has been added, thanks to the work of Patrick Siu and Ravin Dimantha. Now, I don’‘t have a lot (read: any) of experience with SIP/SIMPLE, so I haven’‘t had much luck testing out the support. It’‘s one of those issues where I kind of "don’‘t understand" SIP/SIMPLE enough to know how to test it right. I set up an openser server that has dev SIMPLE support but haven’‘t had a ton of luck, except for connecting to it from X-Lite 3.0 and Gaim 2. Anyway, I’‘d like to ask folk who are familiar with SIP/SIMPLE to please give me whatever feedback you have: if it works, if there was something odd in it’'s behavior, that sort of thing. There are a few known issues with it.
Anyway, the next release of the plugin is likely going to be a 1.0 release candidate, and I hope to have it out over the next couple of weeks. Also note that there were a couple of issues that I believe are taken care of but I could never reproduce in the first place so… I’'m relying on you all to tell me “this is still broken” if I closed the issue. ;D
Thanks folk and enjoy!!
Would you mind explaining what Gate-142 is designed to fix? I know there used to be some issues when the Wildfire server itself lost Internet connectivity the client Rosta froze and the server did not recommend to MSN.
I was hoping it would solve the issue where an MSN client connects to the same account as the Wildfire server and effectively disconnects it.
With Beta 0.8, the disconnect isn’‘t detected by the gateway and therefore the Spark client freezes the MSN rosta. After that point, messages sent to through the MSN gateway for that user appear to be delivered but aren’'t.
I often use Wildfire at work, go home for the evening, chat to a few people using the MSN client then return to work in the morning an continue to use Spark/Wildfire. The net result is that until I log out/in of the MSN gateway within Spark, I cannot see who’'s online or send them messages, although everything appears to work correctly.
Ideally, I’‘d get to work in the morning and my Spark client would nolonger have the MSN users in my rosta - then at least I’'d know the current connection state.
thanks,
D
DeeJay wrote:
Would you mind explaining what Gate-142 is designed to fix? I know there used to be some issues when the Wildfire server itself lost Internet connectivity the client Rosta froze and the server did not recommend to MSN.
Oh sure! =) If you got automatically disconnected from MSN via an IO exception (severed connection), the transport wouldn’'t note that you were logged out, so if you tried to log back in, it would think you were already logged in and not bother trying to log you into the real service. The solution was to have to log all the way out of your XMPP account and back in. Now the logged out state is caught and the logged out flag is set.
I was hoping it would solve the issue where an MSN client connects to the same account as the Wildfire server and effectively disconnects it.
With Beta 0.8, the disconnect isn’‘t detected by the gateway and therefore the Spark client freezes the MSN rosta. After that point, messages sent to through the MSN gateway for that user appear to be delivered but aren’'t.
Interesting. So the problem you were running into sounds like the opposite of what I fixed. I’'m not even seeing the disconnection (in my code that is, just need to preform the event and catch it). GATE-185 Thanks for letting me know!
I often use Wildfire at work, go home for the evening, chat to a few people using the MSN client then return to work in the morning an continue to use Spark/Wildfire. The net result is that until I log out/in of the MSN gateway within Spark, I cannot see who’'s online or send them messages, although everything appears to work correctly.
Ideally, I’‘d get to work in the morning and my Spark client would nolonger have the MSN users in my rosta - then at least I’'d know the current connection state.
Right, it ought to catch the error and “log you out” so to speak. (show the MSN transport as unavailable, and vanish all your users) But yeah, GATE-142 fixed a different issue not directly related to this I think. I’'ll see what I can catch.
Daniel
Great - thanks.
If the same thing happens with 2 MSN clients, the first client will explicitly tell you that someone logged in from another location so you’'d hope the event will be relatively easy to trap.
On a related note - is there anyway to get status notifications back to the Spark client, i.e to inform them of connection failures, or logins from another location? From a user perspective, it’‘d be nice to know why they’'ve been logged out, rather than just assuming ‘‘something went wrong’’.
thanks,
D
Message was edited by: DeeJay
DeeJay wrote:
Great - thanks.
If the same thing happens with 2 MSN clients, the first client will explicitly tell you that someone logged in from another location so you’'d hope the event will be relatively easy to trap.
It should be. =) crossing fingers
On a related note - is there anyway to get status notifications back to the Spark client, i.e to inform them of connection failures, or logins from another location? From a user perspective, it’‘d be nice to know why they’'ve been logged out, rather than just assuming ‘‘something went wrong’’.
Hrm. I’‘m not sure what events would be causing the status notifications not to get through unless Spark is ignoring error type message packets. (I sure hope not) I’‘m explicitly sending error messages in my code. (at least with the errors I catch that are “legit” errors, some of the errors don’‘t mean your connection was severed) Once I get the “you have been disconnected” thing caught, I’'ll defintiely be having it send a message though.
Daniel