Currently Being Moderated

Smack 3.1.0 Beta 1 Released

Posted by Matt Tucker on Oct 30, 2008 10:20:34 PM

We've released the first beta of Smack 3.1.0. Although it's been about a year since the last release, this version is jam-packed with great new features and bug fixes. Check out the changelog for full details.

 

We expect the beta process on the release to be relatively quick, but much will depend on the stability feedback we get. There are also a few last changes that we're looking to get in before the final release.

6,024 Views Tags: planetjabber, smack


Nov 3, 2008 11:48 PM Walter Ebeling Walter Ebeling    says:

Hi Matt,

 

first of all, I'd like to thank your for restarting the work on Smack. I am looking forward to test 3.1.0. b1 and will post observations in the community.

Since you have started the 3.1.0 branch, I would like to ask you to taka a look at the hard coded references to stun.xten.net in the Smack code. From my understanding this URL is used as a fall back for STUN. I am using Spark in a corporate enviroment and have some trouble with our network security team regarding unauthorized connections to stun.xten.net. I would suggest to have that URL as a configurable entry instead of a hard coded reference. The community has reported the issue, but no bug was opened and most of the community members are unsure about the impact of simply removing the URL from the code.

 

Walter Ebeling

Nov 4, 2008 10:58 AM Gaston Dombiak Gaston Dombiak    says in response to Walter Ebeling:

Hey Walter,

 

Thanks for pointing this out. I will forward this info to Jeff that is the STUN/Jingle/VoIP resident expert.

 

  -- Gato

Nov 10, 2008 11:33 AM filipdef filipdef    says:

That's great - I look forward to testing 3.1.0. From scanning the ChangeLog, it seems that the problems with closing the connection haven't been resolved yet (there's a hardcoded time that it waits in the hope that everything will be written to the channel, however, that's not guaranteed - I'm using Smack for some non interactive communication and I find I need to wait a second or two just to be able to guarantee messages actually go out). It'd be really nice if that could be addressed...

Nov 10, 2008 11:39 AM Matt Tucker Matt Tucker    says in response to filipdef:

Hmm... one thing we could do is allow a property to be set where it would wait until the outgoing queue is empty before finalizing the connection close vs. having a max number of seconds. Is that the behavior you're looking for?

Nov 10, 2008 11:44 AM filipdef filipdef    says in response to Matt Tucker:

What I'm looking for is that if I call disconnect() that I can be garanteed that all messages were actually sent. My application has a number of custom jabber commands that get send to various daemons. So, the usage pattern is log in with daemons credentials, send some messages, disconnect. If I can be sure that I don't have to put a sleep before I call disconnect, I'll be very happy :-). To my taste, that makes perfect sense as a default behavior, but it could be controlled by a property or an extra boolean argument to disconnect (e.g. exitImmediately). Thanks for looking into this :-).