[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] Smack lib update for XMPP provider ?

Hello Scott,

on 03.02.2011 00:52, Scott Lewis wrote:
Hi Bjorn,

On 2/2/2011 3:26 PM, Björn Gustavs wrote:
Hi all,

in the current analysis phase of how ECF could be used for Saros (collaboration plugin for Eclipse (http://www.saros-project.org)),
we are looking at the Smack API used in the XMPP provider.

Gladly you are using the latest release - unfortunately Smack isnt maintained regularly.

Have you tried to get these changes accepted by Jive and incorporated into a new version of Smack?  They might be willing to update Smack/produce a new release if you offer to contribute the fixes back to them.

But of course I can't tell you for sure how Jive would/will respond to such an offer.  Unfortunately they have not been updating Smack with new releases in recent past (as you say).

Part of the XMPP improvement task was to try reactivating the Smack development and community. The patches have been offered and posted to the Smack devs and reviews were planned but these efforts "fizzled out" due to lack of manpower and time on Smack side.

I am trying to contact the developer who did the Smack improvements to get to know if there were any updates to this status. But so far I cant get hold of him.

Due to several bugs and incomplete extension implementations, Smack was improved as task of a diploma theses last year.

The improvements (besides bugfixes) are focused in
- Socks5 Bytestream Protocol (more XEP conform, support of dynamic sized streams, more configurations for the proxy, ...)
- In Band Bytestream Implementation (made fully compatible to XEP 0047, bidirectional data exchange, ...)

(more detailed information is available in German in the thesis paper

The thing is now, if using ECF, we cant loose these improvements, because even using ECF we would - for a number of things - use the exposed XMPPConnection for Smack calls.

I considered creating a separate XMPP provider using this updated Smack lib - but that is no optimum.

Another way and the question of this email is:
Would the ECF project consider to absorb these changes - the customized Smack lib - in a way? And if so, in which way?

We *could* do this...as we/ECF have the Smack 3.1.0 source code (org.jivesoftware.smack) in our repository...here:


but it would be much better if these fixes/improvements were accepted into a new version of Smack upstream...and we consumed that new/updated version.

So before we persue changing/fixing our copy of the Smack lib directly, let's explore getting these fixes accepted upstream by Jive (I can help with this if you like Bjorn...as I know Matt Tucker...their CTO...and they are based here in Portland, OR).

If that doesn't work out for whatever reason, then we'll explore applying your fixes to the version of our source we have.

Mmm, seems this effort becomes easy.
I noticed there is actually coming _Smack 3.2_ soon - a beta is available since 2 days. And as far as I see the patches I am talking about are in there.
Magnificent, after 2 years there is movement. =)

So, no need for inofficial patching seems required.

Thanks for your support offer though,