[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ecf-dev] Smack lib update for XMPP provider ?
- From: Björn Gustavs <bjoern.gustavs@xxxxxxxxxxxx>
- Date: Tue, 15 Feb 2011 22:21:31 +0100
- Delivered-to: email@example.com
- User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:18.104.22.168) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7
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.
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
So the focus is changing and being adjusted.
On 02/15/2011 08:38 PM, Björn Gustavs wrote:
Independent of that: our plans to switch to ECF are on hold. After
examining and analyzing the task it became clear, that we wouldn't get
the advantages we planned by switching.
Although ECF wont be out of our scope.
Care to elaborate?
ecf-dev mailing list