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
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.
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,
Björn
|
