Next release?

I realise I won’‘t be able to get a definitive answer to this, and that it’‘s unpredictable because it’'s a ‘‘hobby project’’ but I was wondering when the next release was likely to happen?

I’‘ve been waiting for the MSN gateway to remove people from the roster on disconnects and was hoping it’'d make the next release.

Any clue? days, weeks/month?

Thanks again!

D

Hi,

I have been suffering from the same problem with MSN and decided to take a look at it for myself. In the current code no calls are made to clean up the roster when becoming disconnected. This can easily be solved by inserting the following lines in the logOut() method of MSNSession:

try {

getTransport().cleanUpRoster(getJID(), true, true);

} catch (UserNotFoundException e) {

Log.error("Unable to clean up MSN contact list for " + getJID(), e);

}

I know this is not the most subtle approach (it cleans the roster after each log out), but it seems to do the trick.

Hope this helps,

Lars

Thanks. I’‘ve been resisting the temptation of attempting to fix it myself. Java really isn’‘t my thing. However, I’'ll definately attempt to make those changes and get it into our lab.

Pre version 1.0, updates were frequent and bugs fixed quickly but since then, the focus have seems to be developing more plug-ins.

It’‘s difficult because Jadestorm does this in his own free time so I hate being critical, but personally I think we need more focus on getting the current transports ultra-reliable. It’‘s a shame Jive can’'t persuade him to work for them full time to make the product even better than it already is!

D

Hi Lars! That patch was applied to 1.0.1. Are you still seeing the issue in 1.0.1? (or have you not upgraded to it… it requires openfire =/ )

laugh Actually they’'ve tried. =) I enjoy my real job too much to leave it.

As for the development work… I work at a university. End of semester and lots of deadlines. By the time I get home, not in the mood to code. So when I’‘ve had some time to play with it, I’‘ve just work on things I consider “fun” to poke at a bit. =) Hence, all “new” stuff. That said, a lot of things occured last week that closed up some pending gaps that I was waiting on. Myself and the Jive folk are working out some… I suppose you could call them business plans… about some things. Should improve things from my perspective. … Like… oh… for example… I won’'t have to find out after the fact that the wrong release version was put out.

You all should see some more development coming soon though. All future versions will be for Openfire though, so those that haven’'t upgraded will need to do so to get a hold of the newer ones.

Oh btw! Batch of status updates. There’‘s some good work going on on the yahoo support front. I’‘m excited about that maybe moving to the stable side asap! SIP/SIMPLE will be back soon. GTalk/XMPP is mostly being taken care of by another person. MSN might be moving to a different network communication layer, as I’‘ve got some helpers on that front. ICQ will require a lot of misc work on my part. However I have a good knowledge of how OSCAR works so it shouldn’‘t be hard, and I can send my work back up the pipe to joscar. With the amount of things that are likely to be in the next release … I’‘m having trouble deciding if I should release 1.1.0 or … hell even 2.0. We’'ll see. =)

Anyway, stay tuned! And everyone, please don’‘t forget to vote in the issue tracker for what’'s important to you! MUC/Groupchat and auto reconnects are up at the top of the list right now.

Hi Daniel,

The patch supplied above is not the patch for unregistration I supplied earlier. It’'s a patch for cleaning up the roster when a forced disconnect happens on MSN.

We are actually running (a modified version of) 1.0.1.

Regards, Lars

That’‘s completely understandable, and I’‘m sure I’'d do the same thing (developing interesting stuff rather than minor bugs fixes).

I’'ll look forward to seeing the next release - it certainly sounds interesting!

As far as the disconnects go, the current behaviour I see in Spark is this:

  1. Messages are displayed when the MSN Connection is lost or when a user logs in at another location (which is a big improvement)

  2. Upon clicking the OK dialog after the error the roster is unchanged (i.e. the MSN contacts freeze, never to be updated again)

  3. When you attempt to reconnect to MSN within Spark it doesn’‘t appear to work and future communication to those frozen contacts just tells you you’‘re not connected to MSN (which isn’'t ideal, but much better than appearing to send the message as we used to get)

  4. The only way to fix the inconsistent roster appears to be to logout then back into Spark

Again, it’'s difficult to say how much of this is Spark related and how much the gateways. However, I wish they Jive could convince you use Spark as the client for testing the gateways!

It’‘s great that you enjoy working at the Uni, but a real disadvantage to Jive. From a potential customers perspective (I keep wanting to buy Openfire but always seem to find bugs that irritate our users too much!) the gateway component is a major feature of the product. Honestly, without it we’‘d have already bought Live Communication Server instead. What’‘s concerning me is that even if I do get support with the product, I obviously can’‘t buy the developers time to fix bugs because a) you don’‘t get paid and b) I’‘ve no right to expect anything of a resource that’'s doing this as a hobby with a busy day job!

DeeJay wrote:

From a potential customers perspective (I keep wanting to buy Openfire but always seem to find bugs that irritate our users too much!) the gateway component is a major feature of the product.

Why aren’‘t you using the pytransports then? They’'re actually stable (have been for a few years) and work pretty well here.

To be honest, I didn’‘t know the existed. I’'ll take a closer look at them. They seem better featured too (file transfers etc etc).

There must be a reason for 2 seemingly identical projects to be doing the same thing though?

D

Well there’‘s a couple of reasons. For one, it’‘s always nice to have multiple choices if you ask me. =) In case you don’‘t know this, I am the developer for PyAIM-t and PyICQ-t. Jive saw my work with those and asked me to work on this plugin. (turned out to be a great excuse to learn java, something I’‘d never bothered to do/had a reason to do in the past) The plugin works with openfire and only openfire. The python transports work with any server. =) I still recommend the python transports if you want people who aren’‘t on your server to be able to use the transports. The plugin does not support, and may not ever support, remote users connecting to it. The python transports don’‘t care. =) Of course, since I started working on the plugin, I really haven’‘t had any time to work on the python transports. Hopefully some folk will step up and help with them. Looks like James with PyMSNt also doesn’'t have time to work on it anymore. (said that in a recent mailing list post) Norman from PyYIMt and PyIRCt seems to still be working on his semi regularly though.

As for support, Jive can “bribe” me to take care of certain issues if a support customer requests something specific. Granted I can say no, but hey. My hope is that the code is easy enough to follow that if something comes up, they can also make changes. (they’‘ve made minor tweaks in the past) And who knows, they might hire someone at some point to do full time im gateway plugin. I’'ve got no problem stepping aside if they need me to. =)

Aha, GATE-198 is the one that’'s related to this. Either way, thanks for the patch! =)

(I may be reworking the login status stuff quite a bit, not sure yet)

Too bad the pytransports are no longer maintained…

Another route worth looking into would be to implement a component based on libpurple… That way you could very easily implement 11 different protocols which were already tested on a few hundred thousand machines.

Someone was, btw, planning on what they called at the time “PyGAIMt”, which was supposed to tap into libgaim at the time. I don’'t really know what happened to that.

If you’‘ve got Python skills, I am, btw, looking for folk to develop PyAIMt and PyICQt since I don’'t have time for it anymore. =)

Sorry, my python skills are limited to editing existing blender plugins

PyGAIMt would be kinda complicated, since libpurple is a C library. I think it’'d be better to use iksemel for that.

btw, libpurple only became a separate project very recently (when it got renamed from libgaim), so maybe that’'s why nothing ever happened to that idea.