Yahoo transport may not go production for 1.0 release

Hi folk,

I’‘ve been giving it a lot of thought and talked it over with a couple of folk. I’‘m going to focus on getting the more stable transports ‘‘rock solid’’ and try to push towards a 1.0 release. This means that the Yahoo transport is not likely to be labeled as “stable” anytime soon, and also that I’‘m not likely to be putting a lot of work into it for a bit. I’‘m being told that it’‘s more important to hit a 1.0 sooner so that’‘s what I’‘m going to do. =) The problems with the Yahoo transport is that the library went “stagnant” and the developer hasn’‘t had time to mess with it in a while. So here’'s what I have now:

  • AIM/ICQ: uses joscar, actively developed, pretty solid, just needs some tweaks, very little for me to code/patch here

  • MSN: uses java-jml, i’‘m the lead developer of that nowadays and it’‘s pretty easy to work with. more importantly, i have a good deal of help from it’'s users

  • IRC: IRClib is pretty solid and keeps getting updated regularly. Plus it’'s IRC, not exactly a difficult protocol.

  • Yahoo: jymsg is, unfortunately, stagnant. current svn has a lot of improvements, but doesn’‘t compile and is in a half-done state. no one is actively working on it nor are patches flowing in. I can’‘t take on serious coding on yet another thing right now so I’'m stuck using a “kinda sorta good” library, which clearly has a lot of problems that you all are running into.

So yes, I will certainly be aiming to get Yahoo going, please don’‘t think I’‘m ignoring it. Hell I want Yahoo support to work well as well. But I’‘m going to be putting it off until post 1.0 for now. Now, if some ambitious folk want to try to fix it up and send me patches or whatever, I’‘m all for that, and if it gets solidified because someone else has the drive to make it so, then I’'d be happy to aim for it to be labeled solid in 1.0.

So how is this going to play out? Well, nothing drastic. Basically i’‘m going to separate “stable” from “unstable” transports on the settings page with a little disclaimer. I certainly won’'t be -removing- Yahoo, will just label it as “use at your own risk”.

support your decision!

I’'d definately agree with that.

I’'m really looking forward to the remaining bugs in the MSN transport being nailed though (especially the non recognition of connectivity drops/logouts).

This is a project I’‘ve been following for quite some time. Here’‘s a question: what cannot be leveraged from the gaim project? Gaim and AdiumX work quite well for Yahoo/MSN/AIM/ICQ, couldn’'t this project benefit from their work?

StashTheVampede wrote:

This is a project I’‘ve been following for quite some time. Here’‘s a question: what cannot be leveraged from the gaim project? Gaim and AdiumX work quite well for Yahoo/MSN/AIM/ICQ, couldn’'t this project benefit from their work?

In general, any IM project can benefit from their work (and visa versa, other projects work can be of benefit to them). That said, those are written in C and as far as I know can’‘t be directly used. The only java Yahoo Messenger library I’‘ve ever found is jymsg and the lead developer hasn’‘t done anything with it in a long time. (but has assured me he hasn’‘t given up on it) That said, if I had the time to fix the jymsg library, then this wouldn’‘t be an issue. (or if someone else had the time to fix it so I could then use it) In general though, in my development of PyAIMt and PyICQt, I’'ve benefitted quite a bit from the work the gaim folk already put into it. ;D

And as it turns out, joscar (the thing I used for AIM/ICQ) greatly benefitted from Adium X because they were going to end up using that library… until Apple stopped caring about the mechanism in which they were going to use it. That said, joscar is doing pretty good.

jadestorm wrote:

In general, any IM project can benefit from their work (and visa versa, other projects work can be of benefit to them). That said, those are written in C and as far as I know can’'t be directly used.

Well, you could use them via JNI, but that would defeat the platform independence.

And as it turns out, joscar (the thing I used for AIM/ICQ) greatly benefitted from Adium X because they were going to end up using that library… until Apple stopped caring about the mechanism in which they were going to use it. That said, joscar is doing pretty good.

That and joscar had some very serious issues that couldn’'t be resolved by the Adium developers and delayed the 1.0 release for too long.

Thanks for this decision. I’'m really looking forward for 1.0 release, do you have any idea when you will be able to deliver?

Thanks,

Mélanie

Actually, I’'m not saying anything official yet, but my target goal is end of the month. =)

Could you confirm whether 1.0 will include the reconnection bug fix? i.e. I login to Spark at work, then go home and login to the MSN client. The current behaviour is that Spark does not realise it’‘s connection has been dropped and therefore when I get to work in the morning, the rosta is frozen to the time when I logged into MSN the previous evening (and I generally forget and don’'t get IM messages).

thanks,

D

I will not confirm or deny it until I’'ve had time to look into it.

Ok. There are a few bugs reported about reconnection issues etc and I’'d assumed that it was the same bug but just wanted to check.

The MSN client reports that someone else logged in from a different client in that situation, so I assume the network provides a specific error code (rather that just connection lost).

To be honest, since I’'ve introduced resilient firewall gateways, the IM gateway has been extremely reliable and this is the only ‘‘gotcha’’ that I consider critical before rolling it out to our userbase.

Thanks for all your hard work on this - the IM gateway is a lifesaver!

jadestorm wrote:

Actually, I’'m not saying anything official yet, but my target goal is end of the month. =)

Will 1.0 contain support for MUC? An IRC-gateway without MUC is quite a bummer…

MUC support is not currently on the roadmap for 1.0. I suppose I could kick IRC over to the experimental section as well. Basically all that’‘s supported with IRC is one on one communication. (am I the -only- person who uses IRC like that? hehehe) The Jive folk had talked about building me a base piece for Groupchat/MUC support that I would expand on, but I imagine other priorities have taken over and I haven’'t had time to work on it.