Matthew Rubenstein wrote:
> The names of those objects are so redundant, both in themselves and to
> each other, that they indicated a lot of overcomplexity in the class
> structures. Even if the "sip" in "net.java.sip" is an unfortunate
> overgeneralization of the communicator's "larger sense", the repetition
> of "sip" in both the protocol name and its implementation is at least
> redundant naming, at worst incomplete encapsulation.
The net.java.sip.communicator package is nothing more but the package
prefix that we use for all sip-communicator classes which according to
java naming conventions are based on a related domain name. Being
pedantic would have given us: net.java.dev.sip-communicator (just as it
would have given us net.sf.sip-communicator if we were hosting on
sourceforge). Since however dashes are not allowed in package names we
decided to replace it with a dot. The dev part was also removed as we
did not consider it significant.
OK, some of the "sip" redundancy does indeed derive from the
overgeneralization of the name of the app, which does more protocols
> Likewise the
> repetition of "impl", especially in classes 3 layers apart, indicates
> that either "impl" is used in to very different senses, or that the
> container classes have gotten flipped around somehow.
I don't follow you here. The impl package is supposed to contain roughly
the same tree as the service package. As it name implies it, it contains
implementations of services defined in the service packages.
As for the Impl suffix, it is a common OSGi/Java convention employed by
many projects and JSRs (have a look at jain-sip for example - JSR 32)
when providing API implementations.
OK, the "impl" redundancy does indeed derive from a redundancy
convention redundancy (python intended ;).
> And it appears
> that there's a missing abstract class "Operation"
Would this one do?
Why are the
classes coded as subclasses of
instead of an abstract
class that's subclassed into
or maybe even contained as
> that exists at two
> different degrees of abstraction. Confused/conflated class structures
> are often the result of unplanned, "organic" growth, which also hides
> extra complexity not "designed out" prior to coding. And which can make
> factoring/upgrading code for a truly modular app into a real nightmare,
> especially across multiple developers, and most especially across the
> multiple human languages they might speak.
Was there a question here?
No, more of an explanation of my concern. Redundant naming of classes
is often a clue that a design scheme can be optimized, and that hidden
redundancies and inconsistencies could be factored out. But it's not
proof. Though in this case, it seems more proof of redundancy of some
naming conventions than redundancy of architecture or code.
> Is there a class hierarchy graph somewhere?
No, but this page might be of use:
Thanks. Actually, a class hierarchy would be useful to everyone -
especially people just starting to extend the S-C design to include new
modules that depend on existing functionality.
Hope this helps!
It does, thanks.
On Wed, 2007-05-30 at 15:46 +0200, Emil Ivov wrote:
> On Wed, 2007-05-30 at 12:07 +0200, Emil Ivov wrote:
>> Hello asmouta,
>> Have a look at
>> and its SIP implementation:
>> The method:
>> public void subscribe(String contactIdentifier)
>> seems to be what you are looking for.
>> Hope this helps
>> asmouta wrote:
>>> Hi everybody,
>>> I'm using sip-communicator with only the sip protocol account and I've
>>> already removed the support for other IM protocols (I know that's
>>> strange as I'm doing exactly the inverse of what you do but all I need
>>> is an application supporting sip). Anyways, I need to tell the
>>> sip-communicator, when adding a new contact, that this one will be added
>>> to the default protocol account and to the default group (coz I'll use
>>> just one global group). Is that possible?
>>> I looked into code lines and all I've found is ProtocolProviderService
>>> and I wasn't able to specify the protocol "sip" or the user account that
>>> I'm using.. I mean I want to have some static informations... Hope that
>>> I'm clearly describing my problems, dont hesitate to ask for furthur
>>> Thanks a lot.
>> To unsubscribe, e-mail: email@example.com
>> For additional commands, e-mail: firstname.lastname@example.org
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
(C) Matthew Rubenstein