|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).
Back to the top