Contact display name

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-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>
>>
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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-unsubscribesip-communicator.dev.java.net
>>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>>
>>>
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
> 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net