[sip-comm-dev] Protocol Provider Service


#1

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
explanations.

Thanks a lot.


#2

Hello asmouta,

Have a look at

net.java.sip.communicator.service.protocol.OperationSetPresence

and its SIP implementation:

net.java.sip.communicator.impl.protocol.sip.OperationSetPersistentPresenceSipImpl

The method:

public void subscribe(String contactIdentifier)

seems to be what you are looking for.

Hope this helps
Emil

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 explanations.

Thanks a lot.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

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. 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. And it appears
that there's a missing abstract class "Operation" 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. Is there a class hierarchy
graph somewhere?

···

On Wed, 2007-05-30 at 12:07 +0200, Emil Ivov wrote:

Hello asmouta,

Have a look at

net.java.sip.communicator.service.protocol.OperationSetPresence

and its SIP implementation:

net.java.sip.communicator.impl.protocol.sip.OperationSetPersistentPresenceSipImpl

The method:

public void subscribe(String contactIdentifier)

seems to be what you are looking for.

Hope this helps
Emil

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
> explanations.
>
> Thanks a lot.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hello Matthew,

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.

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.

And it appears
that there's a missing abstract class "Operation"

Would this one do?

net.java.sip.communicator.service.protocol.OperationSet

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?

Is there a class hierarchy graph somewhere?

No, but this page might be of use:
http://www.sip-communicator.org/index.php/Documentation/CreatingServices

Hope this helps!

Emil

···

On Wed, 2007-05-30 at 12:07 +0200, Emil Ivov wrote:

Hello asmouta,

Have a look at

net.java.sip.communicator.service.protocol.OperationSetPresence

and its SIP implementation:

net.java.sip.communicator.impl.protocol.sip.OperationSetPersistentPresenceSipImpl

The method:

public void subscribe(String contactIdentifier)

seems to be what you are looking for.

Hope this helps
Emil

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 explanations.

Thanks a lot.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Thanks Emil for your continuous help, I appreciate and it does really help.
Now, it's time to go back to the code.

···

On 5/30/07, Emil Ivov <emcho@emcho.com> wrote:

Hello asmouta,

Have a look at

net.java.sip.communicator.service.protocol.OperationSetPresence

and its SIP implementation:

net.java.sip.communicator.impl.protocol.sip.OperationSetPersistentPresenceSipImpl

The method:

public void subscribe(String contactIdentifier)

seems to be what you are looking for.

Hope this helps
Emil

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
> explanations.
>
> Thanks a lot.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Hello Matthew,

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
than SIP.

> 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?

net.java.sip.communicator.service.protocol.OperationSet

  So there's
net.java.sip.communicator.service.protocol.OperationSet
and
net.java.sip.communicator.impl.protocol.sip.OperationSetPersistentPresenceSipImpl .

Why are the
n.j.s.c.service
and
n.j.s.c.impl
classes coded as subclasses of
n.j.s.c ,
instead of an abstract
n.j.s.c.service
class that's subclassed into
n.j.s.c.impl ,
or maybe even contained as
n.j.s.c.service.impl ?

> 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:
http://www.sip-communicator.org/index.php/Documentation/CreatingServices

  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:

Emil

> On Wed, 2007-05-30 at 12:07 +0200, Emil Ivov wrote:
>> Hello asmouta,
>>
>> Have a look at
>>
>> net.java.sip.communicator.service.protocol.OperationSetPresence
>>
>> and its SIP implementation:
>>
>> net.java.sip.communicator.impl.protocol.sip.OperationSetPersistentPresenceSipImpl
>>
>> The method:
>>
>> public void subscribe(String contactIdentifier)
>>
>> seems to be what you are looking for.
>>
>> Hope this helps
>> Emil
>>
>> 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
>>> explanations.
>>>
>>> Thanks a lot.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--

(C) Matthew Rubenstein


#7

Hello Matthew,

Matthew Rubenstein wrote:

  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.

If you really need a graphical hierarchy, you have just to give the SIP-Communicator sources to a reverse-engineering methods such as those given by software as "Pos��don" or "Umbrello".

Hope this helps,
Vincent


#8

Matthew,

Matthew Rubenstein wrote:

  So there's
net.java.sip.communicator.service.protocol.OperationSet
and
net.java.sip.communicator.impl.protocol.sip.OperationSetPersistentPresenceSipImpl .

Actually there are many operation set interfaces such as
net.java.sip.communicator.service.protocol.OperationSetPresence
net.java.sip.communicator.service.protocol.OperationSetPersistentPresence
net.java.sip.communicator.service.protocol.OperationSetBasicInstantMessaging
net.java.sip.communicator.service.protocol.OperationSetTypingNotifications
net.java.sip.communicator.service.protocol.OperationSetGeolocation

and they all extend
net.java.sip.communicator.service.protocol.OperationSet

Every protocol implementation may choose to implement one more or all operation set interfaces depending on the functionality it would like to provide. This happens in the impl packages.

Why are the
n.j.s.c.service
and
n.j.s.c.impl
classes coded as subclasses of
n.j.s.c ,
instead of an abstract
n.j.s.c.service
class that's subclassed into n.j.s.c.impl ,

That's exactly how the situation is. Abstract classes in the service packages are extended and implemented by subclasses in the impl packages.

Cheers
Emil

···

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:
http://www.sip-communicator.org/index.php/Documentation/CreatingServices

  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.

Emil

On Wed, 2007-05-30 at 12:07 +0200, Emil Ivov wrote:

Hello asmouta,

Have a look at

net.java.sip.communicator.service.protocol.OperationSetPresence

and its SIP implementation:

net.java.sip.communicator.impl.protocol.sip.OperationSetPersistentPresenceSipImpl

The method:

public void subscribe(String contactIdentifier)

seems to be what you are looking for.

Hope this helps
Emil

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 explanations.

Thanks a lot.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#9

I will. If someone else doesn't beat me to it (hint ;), I will generate
a graph image that can be posted at the project website. That kind of
doc lowers the barrier to entry for new project members who might be
interested, but intimidated.

···

On Wed, 2007-05-30 at 16:31 +0200, Vincent Lucas wrote:

Hello Matthew,

Matthew Rubenstein wrote:
> 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.
>
>
If you really need a graphical hierarchy, you have just to give the
SIP-Communicator sources to a reverse-engineering methods such as those
given by software as "Poséïdon" or "Umbrello".

Hope this helps,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net