[
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.
Scott
