Re: [ecf-dev] Replacing ConnectionConfiguration

[Karl Beecher <karl.beecher@xxxxxxxxxxxx>]

Hi Scott,

Thanks for your answer.

Yes, it seems that adding to the XMPPContainer's capabilities is
inevitable, because we use functionality from the XMPPConnection class
that is not provided by the former (isConnected() is one example that
springs to mind).

If true, the question becomes: how to do this. I would like to do it in
a way that makes it simple to contribute back to the ECF.

My first thought was to inherit a new class from XMPPContainer, but then
it becomes *our* class and thus harder to give back to ECF. Plus, I tend
to favour aggregation over inheritance anyway. Nevertheless, the
inheritance path would solve a few problems (like access to protected
parts of XMPPContainer superclasses), so I have not completely closed it
off.

Perhaps the ideal is to work directly on ECF code. We can patch it for
our needs (e.g. add parts we need to the XMPPContainer), and build our
own jar files for use in our distribution, but also give the patches to
ECF for you to include in ECF proper should you accept them.

I guess you've had questions like this before. Do you have any
policies/best practices for this sort of question?

Thanks
Karl


On Fri, 2010-11-26 at 16:43 +0100, Scott Lewis wrote:
> Hi Karl,
> 
> On 11/26/2010 5:56 AM, Karl Beecher wrote:
> > Hi there,
> >
> > Within my application, I am currently trying to replace Smack's
> > XMPPConnection with ECF's XMPPContainer, about which I have a question.
> >
> > In one instance, we construct an XMPPConnection using the constructor:
> > XMPPConnection(ConnectionConfiguration config)
> >
> > In making the config object we:
> >    - set URI (host and port)
> >    - pass a ProxyInfo object
> >    - call setSecurityMode()
> >    - call setReconnectionAllowed()
> >
> > As far as I can see, an XMPPContainer doesn't accept a
> > ConnectionConfiguration and there is no equivalent in ECF to use.
> > Furthermore, I can't see alternative ways in an XMPPContainer to
> > configure the specific information I list above.
> 
> The equivalent of what you are doing in terms of XMPPConnection creation 
> and connection configuration is done in this class:
> 
> org.eclipse.ecf.internal.provider.xmpp.smack.ECFConnection
> 
> Specifically the equivalent of what you are doing is in the 
> ECFConnection.connect(ID remote, Object data, int timeout) method.
> 
> The ECFConnection instance is actually created for the XMPP container at 
> connect time via this method in class 
> org.eclipse.ecf.provider.xmpp.XMPPContainer:
> 
>      protected ISynchAsynchConnection createConnection(ID remoteSpace,
>              Object data) throws ConnectionCreateException
> 
> If you wanted to enhance the ECFConnection class itself to add further 
> configuration information, then if you contribute it back we can/could 
> add it to the next release.  Another option would be to create a brand 
> new xmpp provider...and override XMPPContainer.createConnection to 
> create your own ECFConnection subclass.
> 
> Thanks,
> 
> Scott
> 
> 
> _______________________________________________
> ecf-dev mailing list
> ecf-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ecf-dev