[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Replacing ConnectionConfiguration
|
Hi Karl,
On 11/26/2010 8:53 AM, Karl Beecher wrote:
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?
Generally, what I prefer is to add API (either through aggregation or
inheritance...e.g. protected methods) so as to generalize things to
handle new use cases. Changing or removing API methods (public or
protected) isn't something we can generally do except in extreme cases.
Even though adding API can imply a major/breaking API version change (at
least according to the Eclipse API tools rules), IMHO it's far less
disruptive to consumers than changing or removing existing API.
One thing to consider...you might try a mixed strategy for some
things...i.e. generalizing ECF API (when necessary) to allow you to
create things specific to your application, and then having your own
application classes that use that API (and that are not part of ECF proper).
Scott
