[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Smack lib update for XMPP provider ?
|
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).
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
http://www.inf.fu-berlin.de/inst/ag-se/theses/Staib10-DPPX.pdf
)
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:
http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/protocols/bundles/org.jivesoftware.smack
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.
Thanks,
Scott
