[sip-comm-dev] LDAP status update


#1

Hi!

It's been a long time since I have reported on this mailing list.

I've just posted on my blog a progress entry about LDAP integration,
with screenshots:
http://mazy.fr/blog/post/2008/07/06/LDAP-status-%3A-backend-and-registration-wizard

Everything is up to date on the svn, branch ldap.

To recap:
- most of the service is done, even if I may modify it to fit the plugin's needs
- the configuration UI is done and if you can test it and give me
feedback, you're welcome :slight_smile:

What's left is mostly UI work in the plugin to answer the following use cases:
- a search and add contact dialog
- the type-first-letters-of-the-correspondent's-name-and-call feature
(脿 la google suggest)
- retrieve a contact group from the directory

I'll start working on the search dialog tomorrow for a week, as it is
the priority feature. If you have any opinion on what is should or
shouldn't do, that's the moment :slight_smile:

I see the search dialog as a three step process:
1) search
2) select a result (= contact/person)
3) select which address/protocol to add as contact

Currently, a search query is a simple string that the service tries to
match to ldap attributes known to store names, such as cn, sn,
givenname. It could be a good idea to let the user specify his own
custom attributes.
I face the same issue for finding the contact addresses, but there the
problem is that there is no widely used attributes for storing IM IDs.
The solution would be to allow the user to tell SIP Communicator these
attributes or to impose our schema. I strongly support the first
option, as it is more flexible :slight_smile:

Cheers,

路路路

--
S茅bastien Mazy


#2

Hello Sebastien,

Thanks for the update!

(more inline)

What's left is mostly UI work in the plugin to answer the following use cases:
- a search and add contact dialog
- the type-first-letters-of-the-correspondent's-name-and-call feature
(脿 la google suggest)
- retrieve a contact group from the directory

I'll start working on the search dialog tomorrow for a week, as it is
the priority feature. If you have any opinion on what is should or
shouldn't do, that's the moment :slight_smile:

I'd definitely see the search dialog as the most important thing here. I
wouldn't necessarily dedicate it to the "add contact" functionality
though. LDAP is very widely used for phone numbers too. I guess I'd call
the dialog something like "Directory Service (LDAP)" and show all
available information (pretty much like the address book in thunderbird
does). It would probably be nice to makes sure that your text panes
support copy/paste so that users can then use this information in
whatever way they like.

Once this is ready you may try to do some parsing and provide users with
a way to call the phone numbers for example. IM IDs would be difficult
to identify automatically so you may simply let the user decide what to
do with them. One possible option to do this would be to have a menu
that allows adding an e-mail address as a contact in any protocol but
even that may be too complicated for the little benefit it would offer
compared to copying and pasting the id.

I see the search dialog as a three step process:
1) search
2) select a result (= contact/person)

These are cool.

3) select which address/protocol to add as contact

That's the part I'd change. Once again, adding a contact is hardly going
to be the primary use case of this component so I'd avoid concentrating
on it that much.

Currently, a search query is a simple string that the service tries to
match to ldap attributes known to store names, such as cn, sn,
givenname. It could be a good idea to let the user specify his own
custom attributes.

I don't know about this. Right now I can't think of anyone (even
developers) who would feel comfortable with having to manually specify
ldap params in order to look up a phone number.

I face the same issue for finding the contact addresses, but there the
problem is that there is no widely used attributes for storing IM IDs.
The solution would be to allow the user to tell SIP Communicator these
attributes or to impose our schema. I strongly support the first
option, as it is more flexible :slight_smile:

Or simply let them copy paste the details that we don't know the meaning
of.

WDYT?

Emil

路路路

Cheers,

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

Thanks for the feedback. I'm currently working on the search dialog
UI, taking your comments into account.

I'd definitely see the search dialog as the most important thing here. I
wouldn't necessarily dedicate it to the "add contact" functionality
though. LDAP is very widely used for phone numbers too. I guess I'd call
the dialog something like "Directory Service (LDAP)" and show all
available information (pretty much like the address book in thunderbird
does). It would probably be nice to makes sure that your text panes
support copy/paste so that users can then use this information in
whatever way they like.

Once this is ready you may try to do some parsing and provide users with
a way to call the phone numbers for example. IM IDs would be difficult
to identify automatically so you may simply let the user decide what to
do with them. One possible option to do this would be to have a menu
that allows adding an e-mail address as a contact in any protocol but
even that may be too complicated for the little benefit it would offer
compared to copying and pasting the id.

Agreed for building an SIP id using the phone number. As for finding
IM ids, we can expect that if a business will use instant messaging,
then it is likely to be jabber and based on the mail address
(user@company.com).

That's the part I'd change. Once again, adding a contact is hardly going
to be the primary use case of this component so I'd avoid concentrating
on it that much.

OK

Currently, a search query is a simple string that the service tries to
match to ldap attributes known to store names, such as cn, sn,
givenname. It could be a good idea to let the user specify his own
custom attributes.

I don't know about this. Right now I can't think of anyone (even
developers) who would feel comfortable with having to manually specify
ldap params in order to look up a phone number.

Actually, you don't have to specify them. They are hard coded.

I'll try to post an UI update tonight, even if incomplete.

Cheers,

路路路

On Tue, Jul 8, 2008 at 11:38 AM, Emil Ivov <emcho@sip-communicator.org> wrote:

--
S茅bastien Mazy


#4

Hey Seb,

S茅bastien Mazy 薪邪锌懈褋邪:

Agreed for building an SIP id using the phone number.

You don't really have to build a URI and I'd actually advise against it.
The SIP provider is doing this already so you simply have to pass the
string to it.

As for finding
IM ids, we can expect that if a business will use instant messaging,
then it is likely to be jabber and based on the mail address
(user@company.com).

Yes absolutely and the same uri could very well be a SIP, MSN or a
Yahoo! Messenger one which could just as well be adopted by a business.
The delicate part comes from the fact that we "expect" without really
being certain. This is why I'd start by making sure that it is easy for
the user to clipboard copy all returned values and use them as they see
fit.

In a later stage we can think of adding extra options such as offering
the user with a way to choose between all uses that a certain URI may fit.

Then again, that would be later on.

Cheers
Emil

路路路

That's the part I'd change. Once again, adding a contact is hardly going
to be the primary use case of this component so I'd avoid concentrating
on it that much.

OK

Currently, a search query is a simple string that the service tries to
match to ldap attributes known to store names, such as cn, sn,
givenname. It could be a good idea to let the user specify his own
custom attributes.

I don't know about this. Right now I can't think of anyone (even
developers) who would feel comfortable with having to manually specify
ldap params in order to look up a phone number.

Actually, you don't have to specify them. They are hard coded.

I'll try to post an UI update tonight, even if incomplete.

Cheers,

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


#5

Hi!

The basic work on the search dialog is over, and I will now focus on
the "脿 la google suggest" search field feature. I've blogged about it
(screenshots included) there:
http://mazy.fr/blog/post/2008/07/07/LDAP-status%3A-Search-dialog-and-future-auto-search-dialog

The search dialog should be able to retrieve the attributes recognized
by popular applications:
http://mazy.fr/blog/post/2008/07/10/Common-LDAP-attributes

Let me paste here the mandatory key points for the new auto-search field:
聽聽聽聽* the auto-search feature should wait for a given amount of
characters to be typed before sending a remote query
聽聽聽聽* once we are sure we have received all the results for a search
query, we should cache these results and search in the cache if the
user adds characters again
聽聽聽聽* consistency: I get the same results if I add a character and
remove it consecutively
聽聽聽聽* provided the auto-search field is an editable combo box, too
many results shouldn't be displayed at the same time
聽聽聽聽* if the user presses enter without any auto-search result
selected, force a new search (ie skip the cache)
聽聽聽聽* the auto-search field should be a reusable component

As usual, I look forward your feedback!

You don't really have to build a URI and I'd actually advise against it.
The SIP provider is doing this already so you simply have to pass the
string to it.

OK. So a simple cleanup of the telephone number will do (basically
strip dots and blanks)

As for finding
IM ids, we can expect that if a business will use instant messaging,
then it is likely to be jabber and based on the mail address
(user@company.com).

Yes absolutely and the same uri could very well be a SIP, MSN or a
Yahoo! Messenger one which could just as well be adopted by a business.
The delicate part comes from the fact that we "expect" without really
being certain. This is why I'd start by making sure that it is easy for
the user to clipboard copy all returned values and use them as they see
fit.

You're right. A paste button will soon be available (see blog entry).

Cheers,

路路路

On Thu, Jul 10, 2008 at 5:49 PM, Emil Ivov <emcho@sip-communicator.org> wrote:

--
S茅bastien Mazy