[sip-comm-dev] Contact display name


#1

Hi all,

In many case, Contact#getDisplayName() returns the contact's address while we can
expect a more user friendly result. For example, the display name
of the meta contact enclosing the contact, as showed in the GUI.

Can we modify the displayName of a contact (when possible) to match
the one's of in enclosing meta contact.
So,
    MetaContact#setDisplayName()
will modify the meta contact display name and sync it with all enclosed
contacts wich supports display name modification.

regards.

···

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

Yes good idea. Right now MetaContact-s retrieve display names through
the Contact.getDisplayName() method when they are created. In most
protocols the getDisplayName() method would return a display name if it
exists and the contact address otherwise.

This is as far as we go in trying to be intelligent when handling
display names.

After a MetaContact has been created it doesn't update its display name
from the protocol contacts anymore, because the user might have changed
it locally. Yet, I hadn't actually thought about the opposite thing,
that is the possibility of forcing the MetaContact display name on
protocol contacts, which is what you suggest.

Probably the easiest way to do this would be to only enforce consistency
when users themselves change the name. We could say that in situations
where we start and find certain meta contacts that contain a contact
which has a different display name - we don't do anything because we
don't really know which is the "most valid name".

Forcing the display name upon a merge is also not a good idea because
this could lead to a situation where a contact from one protocol (e.g.
GoogleTalk) ends up with a display name that is actually the address
from another protocol contact (e.g. msn). If we unmerge the contacts at
that point, we'd have a confusing state where two different contacts
appear to have the same address, whereas actually it would only be a
display name for one of them.

However, if we stick to the rule that we only modify contact display
names for all contacts in a meta contact, after the user has explicitly
renamed it, I think we should be fine.

How does this sound?

Emil

Sympho wrote:

···

Hi all,

In many case, Contact#getDisplayName() returns the contact's address
while we can
expect a more user friendly result. For example, the display name
of the meta contact enclosing the contact, as showed in the GUI.

Can we modify the displayName of a contact (when possible) to match
the one's of in enclosing meta contact.
So,
    MetaContact#setDisplayName()
will modify the meta contact display name and sync it with all enclosed
contacts wich supports display name modification.

regards.

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

See at end

Emil Ivov a �crit :

Hi Sympho,

Yes good idea. Right now MetaContact-s retrieve display names through
the Contact.getDisplayName() method when they are created. In most
protocols the getDisplayName() method would return a display name if it
exists and the contact address otherwise.

This is as far as we go in trying to be intelligent when handling
display names.

After a MetaContact has been created it doesn't update its display name
from the protocol contacts anymore, because the user might have changed
it locally. Yet, I hadn't actually thought about the opposite thing,
that is the possibility of forcing the MetaContact display name on
protocol contacts, which is what you suggest.

Probably the easiest way to do this would be to only enforce consistency
when users themselves change the name. We could say that in situations
where we start and find certain meta contacts that contain a contact
which has a different display name - we don't do anything because we
don't really know which is the "most valid name".

Forcing the display name upon a merge is also not a good idea because
this could lead to a situation where a contact from one protocol (e.g.
GoogleTalk) ends up with a display name that is actually the address
from another protocol contact (e.g. msn). If we unmerge the contacts at
that point, we'd have a confusing state where two different contacts
appear to have the same address, whereas actually it would only be a
display name for one of them.

However, if we stick to the rule that we only modify contact display
names for all contacts in a meta contact, after the user has explicitly
renamed it, I think we should be fine.

It is exactly what I was saying :).

I have added
  Contact#setDisplayName(String displayName);
to the contact interface. Only the Jabber implementation works as wanted.

Display name of msn contacts can be modified with
  MsnMessenger#renameFriend(Email email, String name);
but it doesn't works as expected.

Some protocols don't provide api to perform such task.

++ Sympho

···

How does this sound?

Emil

Sympho wrote:

Hi all,

In many case, Contact#getDisplayName() returns the contact's address while we can
expect a more user friendly result. For example, the display name
of the meta contact enclosing the contact, as showed in the GUI.

Can we modify the displayName of a contact (when possible) to match
the one's of in enclosing meta contact.
So,
    MetaContact#setDisplayName()
will modify the meta contact display name and sync it with all enclosed
contacts wich supports display name modification.

regards.

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


#4

Hi Sympho,

We need to discuss this further.

Contacts are supposed to be passive objects. They are not intended to be
used for modifications (this why they only had get methods).

The main reason for this is that contact modification varies greatly
across protocols. As you have noticed, some stacks support it, others
don't. In some cases (e.g. Bonjour, SIMPLE) it doesn't even make sense
because there is no server stored contact list.

So I think the best way to have this is in some operation set, and it
seems to me that OperationSetServerStoredContactInfo is the place to
have it.

We'd possibly need to add a "getMutableDetails()" method and another
setDetail() one.

Let's think about this some more.

Emil

Sympho wrote:

···

Hi Emil,

See at end

Emil Ivov a �crit :

Hi Sympho,

Yes good idea. Right now MetaContact-s retrieve display names through
the Contact.getDisplayName() method when they are created. In most
protocols the getDisplayName() method would return a display name if it
exists and the contact address otherwise.

This is as far as we go in trying to be intelligent when handling
display names.

After a MetaContact has been created it doesn't update its display name
from the protocol contacts anymore, because the user might have changed
it locally. Yet, I hadn't actually thought about the opposite thing,
that is the possibility of forcing the MetaContact display name on
protocol contacts, which is what you suggest.

Probably the easiest way to do this would be to only enforce consistency
when users themselves change the name. We could say that in situations
where we start and find certain meta contacts that contain a contact
which has a different display name - we don't do anything because we
don't really know which is the "most valid name".

Forcing the display name upon a merge is also not a good idea because
this could lead to a situation where a contact from one protocol (e.g.
GoogleTalk) ends up with a display name that is actually the address
from another protocol contact (e.g. msn). If we unmerge the contacts at
that point, we'd have a confusing state where two different contacts
appear to have the same address, whereas actually it would only be a
display name for one of them.

However, if we stick to the rule that we only modify contact display
names for all contacts in a meta contact, after the user has explicitly
renamed it, I think we should be fine.

It is exactly what I was saying :).

I have added
  Contact#setDisplayName(String displayName);
to the contact interface. Only the Jabber implementation works as wanted.

Display name of msn contacts can be modified with
  MsnMessenger#renameFriend(Email email, String name);
but it doesn't works as expected.

Some protocols don't provide api to perform such task.

++ Sympho

How does this sound?

Emil

Sympho wrote:

Hi all,

In many case, Contact#getDisplayName() returns the contact's address
while we can
expect a more user friendly result. For example, the display name
of the meta contact enclosing the contact, as showed in the GUI.

Can we modify the displayName of a contact (when possible) to match
the one's of in enclosing meta contact.
So,
    MetaContact#setDisplayName()
will modify the meta contact display name and sync it with all enclosed
contacts wich supports display name modification.

regards.

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

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