[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/15/2011 1:21 PM, Björn Gustavs wrote:
We already build heavily on Smack API. Next to messaging, roster and presence functionality there are several low level XMPP/Smack accesses (File transfer fallbacks, handle difficult network scenarios, ServiceDiscovery, Jingle, Smack Debug, ...) we use.

Our main goal was to be able to get rid of parts of our network code without loosing established features.
ECF provides great APIs but those serving our current needs often encapsulates the Smack API calls we already use (like the XMPPContainerAccountManager wrapping the smack.AccountManager).

So our network code would often shift from accessing Smack to ECF, but the abstraction wouldn't rise so much that we could outsource parts of our network code. So the task of a network port to ECF didnt got the votes.

I don't fully understand this...as for most of the APIs you listed (presence/roster, filetransfer, discovery, Jingle/telephony) we have corresponding abstract APIs (e.g. presence, filetransfer, discovery, datashare, sharedobject, telephony)...and further we have impls of those APis that actually use the Smack as the provider implementation...at least that is true for presence, filetransfer, discovery, telephony. Further, it's quite feasible to create/add new API (and/or enhance the existing APis) to use XMPP-specific (or even Smack-specific) capabilities...if needed.

Further, there's nothing that prevents you from also accessing the Smack API directly...for parts of your code that are tightly bound to that one implementation of that one protocol (xmpp).

So in effect, you can have both...integrate with the ECF APIs that you want/can do, while continuing to use Smack APIs directly (as your app apparently already does). Or make the changeover gradually (one API at a time)...as opposed to a cut-over strategy. I was actually under the impression that a gradual changeover was what was planned...but I suppose that's just an assumption that I made based upon previous postings...limited resources all around, etc.

Still there are advantages of using ECF - that also Scott mentioned - we dont want to deny ourselves.
So its in discussion to - if not port the main network communication now - but to use ECF as base for future functionality (use other ECF APIs, OSGi remote services, Cola) and to keep the portal to you networking and collaboration experts.

Still seems like a good idea to me.