[sip-comm-dev] LDAP support in SIP Communicator


#1

Hi Seb (Mazy) :),

I've talked to Emil off-list and he mentioned that you had some intentions to implement LDAP support in SIP Communicator. I'm very happy to hear that ! I'm currently working on some interfaces and implementation in the user interface that would allow any plugin to register as a search source in the contact list, which should allow you to show LDAP results in the contact list. I should be able to commit all this (or at least the interfaces you'll need) later today or tomorrow. We can then adjust the service, while proceeding with the LDAP implementation.

Cheers,
Yana

···

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


#2

Hi Seb,

Just wanted to let you know that I've committed a first version of search source interfaces. I've tried to make them fit the existing ldap service in sip-communicator.dev.java.net/svn/sip-communicator/branches/ldap and I'd be happy to hear your opinion if you have some time to have a look. I also wanted to ask you what do you think about the idea of triggering events for a list of contacts and not for every found contact. Would this be possible regarding the ldap implementation? I just think this could make the search faster.

Cheers,
Yana

···

On Feb 22, 2010, at 9:05 AM, Yana Stamcheva wrote:

Hi Seb (Mazy) :),

I've talked to Emil off-list and he mentioned that you had some intentions to implement LDAP support in SIP Communicator. I'm very happy to hear that ! I'm currently working on some interfaces and implementation in the user interface that would allow any plugin to register as a search source in the contact list, which should allow you to show LDAP results in the contact list. I should be able to commit all this (or at least the interfaces you'll need) later today or tomorrow. We can then adjust the service, while proceeding with the LDAP implementation.

Cheers,
Yana

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


#3

Hi Yana,

Just wanted to let you know that I've committed a first version
of search source interfaces. I've tried to make them fit the
existing ldap service in
sip-communicator.dev.java.net/svn/sip-communicator/branches/ldap
and I'd be happy to hear your opinion if you have some time to have a look.

Thank you. I have two small remarks otherwise it seems fine to me:

1) I would move getPreferredTelephonyProvider from
ContactSourceService to SourceContact.
Example : a search returns two contacts, one with a phone number (to
be called with SIP),
the other with a jabber ID (to be called with XMPP+Jingle)

2) queryContactSource(Pattern) will be difficult to implement, because
one cannot be sure that
the underlying protocol will support the same search combinations as
Pattern. Could it be
made at least optional ?

I also wanted to ask you what do you think about the idea of triggering events
for a list of contacts and not for every found contact. Would this be possible
regarding the ldap implementation? I just think this could make the search faster.

JNDI returns the results one by one as they come from the remote
directory, and these are
imediately translated as events. Do you mean faster because we could
spare to refresh the
UI too often if the contact list received bulk results for contact
searches, or because
events themselves cost too much performance ?

Cheers,

···

On Tue, Mar 9, 2010 at 10:53 PM, Yana Stamcheva <yana@sip-communicator.org> wrote:

--
Sébastien Mazy

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


#4

Hi Seb,

Thank you for your prompt mail! I know that you're very busy right now and I appreciate it a lot that you're helping me with this one!

(more inline)

Hi Yana,

Just wanted to let you know that I've committed a first version
of search source interfaces. I've tried to make them fit the
existing ldap service in
sip-communicator.dev.java.net/svn/sip-communicator/branches/ldap
and I'd be happy to hear your opinion if you have some time to have a look.

Thank you. I have two small remarks otherwise it seems fine to me:

1) I would move getPreferredTelephonyProvider from
ContactSourceService to SourceContact.
Example : a search returns two contacts, one with a phone number (to
be called with SIP),
the other with a jabber ID (to be called with XMPP+Jingle)

You're absolutely right. After discussing this some more with Emil off-list he pointed me some other important cases and we agreed on a ContactDetail class that would give us access to such information (have a look at revision 6874).

I've seen that you also have some information regarding the contact, like for example first name, sir name, organisation and department, which are not communication details, so I'm now thinking if it could be a good idea to name the current ContactDetail a CommunicationDetail and have two methods in the SourceContact:

Map<String, String> getContactDetails(); - which will return a map of the above non communication details, and:
List<CommunicationDetail> getCommunicationDetails(); - which will return the list of communication details, like phone numbers, emails, etc. (i.e. the ones that you could chat or call through)

WDYT? Emil?

2) queryContactSource(Pattern) will be difficult to implement, because
one cannot be sure that
the underlying protocol will support the same search combinations as
Pattern. Could it be
made at least optional ?

Ok I see. I've added an ExtendedContactSourceService which contains the queryContactSource(Pattern) method. It's meant to be used in cases, where searching using a pattern is possible, like for example in the history service. The advantages of a pattern are that, we could directly define some constrains for the search and thus we could ensure a result that corresponds to the given constraints, for example case insensitive search, etc. However I absolutely agree that this should be just an option and is not applicable in all cases.

I also wanted to ask you what do you think about the idea of triggering events
for a list of contacts and not for every found contact. Would this be possible
regarding the ldap implementation? I just think this could make the search faster.

JNDI returns the results one by one as they come from the remote
directory, and these are
imediately translated as events. Do you mean faster because we could
spare to refresh the
UI too often if the contact list received bulk results for contact
searches, or because
events themselves cost too much performance ?

I was thinking more of the refreshing issue and was looking for some way to notify the UI for a bunch of contacts, instead of for each contact and was just curious how it happens on lower level. However it all depends on the time of response of a query. In the case of LDAP query it could be better if contacts are coming one by one and the user sees it, instead of make him wait for seeing all the contacts at once.

Cheers,
Yana

···

On Mar 10, 2010, at 7:09 PM, Sébastien Mazy wrote:

On Tue, Mar 9, 2010 at 10:53 PM, Yana Stamcheva > <yana@sip-communicator.org> wrote:

Cheers,

--
Sébastien Mazy

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

1) I would move getPreferredTelephonyProvider from
ContactSourceService to SourceContact. Example : a search returns
two contacts, one with a phone number (to be called with SIP),
the other with a jabber ID (to be called with XMPP+Jingle)

You're absolutely right. After discussing this some more with Emil
off-list he pointed me some other important cases and we agreed on a
ContactDetail class that would give us access to such information
(have a look at revision 6874).

I've seen that you also have some information regarding the contact,
like for example first name, sir name, organisation and department,
which are not communication details, so I'm now thinking if it could
be a good idea to name the current ContactDetail a
CommunicationDetail and have two methods in the SourceContact:

Map<String, String> getContactDetails(); - which will return a map
of the above non communication details, and:
List<CommunicationDetail> getCommunicationDetails(); - which will
return the list of communication details, like phone numbers, emails,
etc. (i.e. the ones that you could chat or call through)

WDYT? Emil?

I agree. It seems flexible enough.

2) queryContactSource(Pattern) will be difficult to implement,
because one cannot be sure that the underlying protocol will
support the same search combinations as Pattern. Could it be made
at least optional ?

Ok I see. I've added an ExtendedContactSourceService which contains
the queryContactSource(Pattern) method. It's meant to be used in
cases, where searching using a pattern is possible, like for example
in the history service. The advantages of a pattern are that, we
could directly define some constrains for the search and thus we
could ensure a result that corresponds to the given constraints, for
example case insensitive search, etc. However I absolutely agree that
this should be just an option and is not applicable in all cases.

Thanks!

I also wanted to ask you what do you think about the idea of
triggering events for a list of contacts and not for every
found contact. Would this be possible regarding the ldap
implementation? I just think this could make the search
faster.

JNDI returns the results one by one as they come from the remote
directory, and these are imediately translated as events. Do you
mean faster because we could spare to refresh the UI too often if
the contact list received bulk results for contact searches, or
because events themselves cost too much performance ?

I was thinking more of the refreshing issue and was looking for some
way to notify the UI for a bunch of contacts, instead of for each
contact and was just curious how it happens on lower level. However
it all depends on the time of response of a query. In the case of
LDAP query it could be better if contacts are coming one by one and
the user sees it, instead of make him wait for seeing all the
contacts at once.

For a local contact source, it actually makes sense to notify of several results at once, as you proposed. ContactReceivedEvent would then contain a collection of SourceContact. It would not prevent the LDAP implementation from sending only one contact per event.

Just a thought. If several contact sources are available, do we plan to be able to search several of them with a single query?

Cheers,

···

On 03/11/2010 10:54 PM, Yana Stamcheva wrote:

--
S�bastien

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