[jitsi-dev] XCAP Contact caching


#1

Hi,

It seems to me there is a problem with xcap contacts caching in
.jitsi/contactlist.xml

For example if XCAP sends:

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <list name="Work">
    <entry uri="10001@sip.example.com">
      <display-name>Christopher Jones</display-name>
    </entry>
  </list>
</resource-lists>

this is saved in .jitsi/contactlist.xml

If some time later the above contact is renamed from "Christopher
Jones" to "Chris Jones",
the expected behaviour would be for Jitsi to update contactlist.xml
and GUI accordingly and show "Chris Jones"

However at the moment this doesn't happen and Jitsi continues to
display "old" contact name.

Thanks and best regards,
Chris


#2

Hi, to clarify my example below:
the renaming of a contact happens not in Jitis but for example XCAP
Web Interface.

Regards,
Chris

···

On 17 August 2011 09:47, Chris Maciejewski <chris@wima.co.uk> wrote:

Hi,

It seems to me there is a problem with xcap contacts caching in
.jitsi/contactlist.xml

For example if XCAP sends:

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list name="Work">
<entry uri="10001@sip.example.com">
<display-name>Christopher Jones</display-name>
</entry>
</list>
</resource-lists>

this is saved in .jitsi/contactlist.xml

If some time later the above contact is renamed from "Christopher
Jones" to "Chris Jones",
the expected behaviour would be for Jitsi to update contactlist.xml
and GUI accordingly and show "Chris Jones"

However at the moment this doesn't happen and Jitsi continues to
display "old" contact name.

Thanks and best regards,
Chris


#3

Hi Emil,

Thanks for clarification.

What happens if I have Jitsi installed on my PC and a laptop. Both
using the same SIP/XCAP accounts.

Now lets say I renamed a contact on my PC. At the moment this will not
be reflected on a laptop? IMHO this isn't a correct behaviour.

Best regards,
Chris

···

On 18 August 2011 07:50, Emil Ivov <emcho@jitsi.org> wrote:

Hey Chris,

On 17 août 2011, at 10:47, Chris Maciejewski <chris@wima.co.uk> wrote:

Hi,

It seems to me there is a problem with xcap contacts caching in
.jitsi/contactlist.xml

For example if XCAP sends:

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list name="Work">
<entry uri="10001@sip.example.com">
<display-name>Christopher Jones</display-name>
</entry>
</list>
</resource-lists>

this is saved in .jitsi/contactlist.xml

If some time later the above contact is renamed from "Christopher
Jones" to "Chris Jones",
the expected behaviour would be for Jitsi to update contactlist.xml
and GUI accordingly and show "Chris Jones"

However at the moment this doesn't happen and Jitsi continues to
display "old" contact name.

Indeed. The name you see in the contact list is the MetaContact name. Originally, when a MetaContact is created it would borrow the name of the proto contact it encapsulates. Once it has been created though, the MetaContact stops tracking the proto contact name so it won't reflect changes in there. There are two reasons for this:

- after it was created, the name of the meta contact might have been set by the user to something that makes sense to them so re-switching to the protocol name wouldn't be apropriate

- the meta contact might contain multiple proto contacts with different names so making its name match one of them would make it different from the others.

I am not saying this is the right behaviour but any changes would have to take the above into account. If there's anyone interested in contributing a patch we can discuss this further.

Cheers,
Emil

--sent from my mobile

Thanks and best regards,
Chris


#4

This might not be a coreect behavior but Jitsi isn't an online service as all the other services it deals with. Thus there is no global communication between different running instances, no matter on which computer they are running.

For this reason, you cannot really synchronize your differents installations other than sharing the folder that contains the configuration of jitsi. Even with that folder shared, there will be problems to update 2 jitsi's instances that are running at the same time.

Maybe you can achieve something with privisionning (not sure if you can manage contacts with it). But if you can use provisionning, you'll have to update the configuration by another mean to get the changes reflected in the provisionning. And the other will probably see the changes on restart.

Richard

···

On 2011-08-18, at 05:57, Chris Maciejewski <chris@wima.co.uk> wrote:

Hi Emil,

Thanks for clarification.

What happens if I have Jitsi installed on my PC and a laptop. Both
using the same SIP/XCAP accounts.

Now lets say I renamed a contact on my PC. At the moment this will not
be reflected on a laptop? IMHO this isn't a correct behaviour.

Best regards,
Chris

On 18 August 2011 07:50, Emil Ivov <emcho@jitsi.org> wrote:

Hey Chris,

On 17 août 2011, at 10:47, Chris Maciejewski <chris@wima.co.uk> wrote:

Hi,

It seems to me there is a problem with xcap contacts caching in
.jitsi/contactlist.xml

For example if XCAP sends:

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list name="Work">
   <entry uri="10001@sip.example.com">
     <display-name>Christopher Jones</display-name>
   </entry>
</list>
</resource-lists>

this is saved in .jitsi/contactlist.xml

If some time later the above contact is renamed from "Christopher
Jones" to "Chris Jones",
the expected behaviour would be for Jitsi to update contactlist.xml
and GUI accordingly and show "Chris Jones"

However at the moment this doesn't happen and Jitsi continues to
display "old" contact name.

Indeed. The name you see in the contact list is the MetaContact name. Originally, when a MetaContact is created it would borrow the name of the proto contact it encapsulates. Once it has been created though, the MetaContact stops tracking the proto contact name so it won't reflect changes in there. There are two reasons for this:

- after it was created, the name of the meta contact might have been set by the user to something that makes sense to them so re-switching to the protocol name wouldn't be apropriate

- the meta contact might contain multiple proto contacts with different names so making its name match one of them would make it different from the others.

I am not saying this is the right behaviour but any changes would have to take the above into account. If there's anyone interested in contributing a patch we can discuss this further.

Cheers,
Emil

--sent from my mobile

Thanks and best regards,
Chris


#5

Hey Chris,

На 18.08.11 11:57, Chris Maciejewski написа:

Hi Emil,

Thanks for clarification.

What happens if I have Jitsi installed on my PC and a laptop. Both
using the same SIP/XCAP accounts.

Now lets say I renamed a contact on my PC. At the moment this will not
be reflected on a laptop?

The change will be reflected on the PC and the XCAP server. The laptop
would not show it.

IMHO this isn't a correct behaviour.

I guess this is pretty much what I meant when I said:

I am not saying this is the right behaviour

:slight_smile:

Patches are hence welcome.

Cheers,
Emil

···

Best regards,
Chris

On 18 August 2011 07:50, Emil Ivov <emcho@jitsi.org> wrote:

Hey Chris,

On 17 août 2011, at 10:47, Chris Maciejewski <chris@wima.co.uk> wrote:

Hi,

It seems to me there is a problem with xcap contacts caching in
.jitsi/contactlist.xml

For example if XCAP sends:

<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list name="Work">
   <entry uri="10001@sip.example.com">
     <display-name>Christopher Jones</display-name>
   </entry>
</list>
</resource-lists>

this is saved in .jitsi/contactlist.xml

If some time later the above contact is renamed from "Christopher
Jones" to "Chris Jones",
the expected behaviour would be for Jitsi to update contactlist.xml
and GUI accordingly and show "Chris Jones"

However at the moment this doesn't happen and Jitsi continues to
display "old" contact name.

Indeed. The name you see in the contact list is the MetaContact name. Originally, when a MetaContact is created it would borrow the name of the proto contact it encapsulates. Once it has been created though, the MetaContact stops tracking the proto contact name so it won't reflect changes in there. There are two reasons for this:

- after it was created, the name of the meta contact might have been set by the user to something that makes sense to them so re-switching to the protocol name wouldn't be apropriate

- the meta contact might contain multiple proto contacts with different names so making its name match one of them would make it different from the others.

I am not saying this is the right behaviour but any changes would have to take the above into account. If there's anyone interested in contributing a patch we can discuss this further.

Cheers,
Emil

--sent from my mobile

Thanks and best regards,
Chris

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#6

Indeed Jitsi isn't an online service, but XCAP server (which Jitsi can
use to store contact lists and other presence information) is a
network service that can be accessed by any number of Jitsi instances
and serve as a common synchronisation tool. (BTW: this is one of the
main reasons XCAP was developed in the first place).

I am thinking if storing contacts locally when XCAP is enabled is
required / needed at all?

Maybe if XCAP is enabled Jitsi shouldn't use contactlist.xml for SIP
contact storage at all? And use exclusively XCAP service instead? Of
course this would mean no access to contact in case XCAP server is
unavailable. But on the other hand in most cases if XCAP is down, SIP
proxy/registrar will be down too and user will not be able to make
calls anyway.

Just a thought... Any comments on this? Is there any reason why
contactlist.xml might be required when XCAP is used?

Regards,
Chris

···

On 18 August 2011 11:53, Richard Lavoie <lavoie.richard@gmail.com> wrote:

This might not be a coreect behavior but Jitsi isn't an online service as all the other services it deals with. Thus there is no global communication between different running instances, no matter on which computer they are running.

For this reason, you cannot really synchronize your differents installations other than sharing the folder that contains the configuration of jitsi. Even with that folder shared, there will be problems to update 2 jitsi's instances that are running at the same time.

Maybe you can achieve something with privisionning (not sure if you can manage contacts with it). But if you can use provisionning, you'll have to update the configuration by another mean to get the changes reflected in the provisionning. And the other will probably see the changes on restart.

Richard


#7

Hi,

the local contactlist storage is required cause there are local
settings for the contactlist as there are many protocols and contacts
can be merged, contacts can have common display name. And this is the
reason of the current behavior, cause of the multi-protocol type of
the contact list. If Jitsi is using only XCAP for storing contacts and
no other protocols are available, using only the serverside list will
be reasonable, but when you merge it with other protocols you got
current situation. This are my thoughts on the subject, correct me if
I'm wrong :slight_smile:

Regards
damencho

···

On Fri, Aug 19, 2011 at 11:28 AM, Chris Maciejewski <chris@wima.co.uk> wrote:

Indeed Jitsi isn't an online service, but XCAP server (which Jitsi can
use to store contact lists and other presence information) is a
network service that can be accessed by any number of Jitsi instances
and serve as a common synchronisation tool. (BTW: this is one of the
main reasons XCAP was developed in the first place).

I am thinking if storing contacts locally when XCAP is enabled is
required / needed at all?

Maybe if XCAP is enabled Jitsi shouldn't use contactlist.xml for SIP
contact storage at all? And use exclusively XCAP service instead? Of
course this would mean no access to contact in case XCAP server is
unavailable. But on the other hand in most cases if XCAP is down, SIP
proxy/registrar will be down too and user will not be able to make
calls anyway.

Just a thought... Any comments on this? Is there any reason why
contactlist.xml might be required when XCAP is used?

Regards,
Chris

On 18 August 2011 11:53, Richard Lavoie <lavoie.richard@gmail.com> wrote:

This might not be a coreect behavior but Jitsi isn't an online service as all the other services it deals with. Thus there is no global communication between different running instances, no matter on which computer they are running.

For this reason, you cannot really synchronize your differents installations other than sharing the folder that contains the configuration of jitsi. Even with that folder shared, there will be problems to update 2 jitsi's instances that are running at the same time.

Maybe you can achieve something with privisionning (not sure if you can manage contacts with it). But if you can use provisionning, you'll have to update the configuration by another mean to get the changes reflected in the provisionning. And the other will probably see the changes on restart.

Richard


#8

Hey Chris,

На 19.08.11 10:28, Chris Maciejewski написа:

Maybe if XCAP is enabled Jitsi shouldn't use contactlist.xml for SIP
contact storage at all? And use exclusively XCAP service instead? Of
course this would mean no access to contact in case XCAP server is
unavailable. But on the other hand in most cases if XCAP is down, SIP
proxy/registrar will be down too and user will not be able to make
calls anyway.

Just a thought... Any comments on this? Is there any reason why
contactlist.xml might be required when XCAP is used?

Contacts are always stored locally, regardless of whether or not they
are also stored online. We need this to be the case so that users to see
them when they are not connected (e.g. could be helpful if we need to
check one of the numbers or an XMPP address that's also a mail) and most
of all because that's how we store contact relations like those that
group contacts from different accounts into a single meta contact.

Cheers,
Emil

···

Regards,
Chris

On 18 August 2011 11:53, Richard Lavoie <lavoie.richard@gmail.com> wrote:

This might not be a coreect behavior but Jitsi isn't an online service as all the other services it deals with. Thus there is no global communication between different running instances, no matter on which computer they are running.

For this reason, you cannot really synchronize your differents installations other than sharing the folder that contains the configuration of jitsi. Even with that folder shared, there will be problems to update 2 jitsi's instances that are running at the same time.

Maybe you can achieve something with privisionning (not sure if you can manage contacts with it). But if you can use provisionning, you'll have to update the configuration by another mean to get the changes reflected in the provisionning. And the other will probably see the changes on restart.

Richard

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#9

The simplest workaround (in code) might be to count the number of contacts inside a meta-contact. If it's only one contact, then we could use the name that comes from the XCAP server to update the meta-contact.

Ingo

···

-----Original Message-----
From: damencho@damencho.com [mailto:damencho@damencho.com] On Behalf Of
Damian Minkov
Sent: Freitag, 19. August 2011 11:22
To: dev@jitsi.java.net
Subject: [jitsi-dev] Re: XCAP Contact caching
Hi,

the local contactlist storage is required cause there are local
settings for the contactlist as there are many protocols and contacts
can be merged, contacts can have common display name. And this is the
reason of the current behavior, cause of the multi-protocol type of
the contact list. If Jitsi is using only XCAP for storing contacts and
no other protocols are available, using only the serverside list will
be reasonable, but when you merge it with other protocols you got
current situation. This are my thoughts on the subject, correct me if
I'm wrong :slight_smile:

Regards
damencho

On Fri, Aug 19, 2011 at 11:28 AM, Chris Maciejewski <chris@wima.co.uk> > wrote:

Indeed Jitsi isn't an online service, but XCAP server (which Jitsi can
use to store contact lists and other presence information) is a
network service that can be accessed by any number of Jitsi instances
and serve as a common synchronisation tool. (BTW: this is one of the
main reasons XCAP was developed in the first place).

I am thinking if storing contacts locally when XCAP is enabled is
required / needed at all?

Maybe if XCAP is enabled Jitsi shouldn't use contactlist.xml for SIP
contact storage at all? And use exclusively XCAP service instead? Of
course this would mean no access to contact in case XCAP server is
unavailable. But on the other hand in most cases if XCAP is down, SIP
proxy/registrar will be down too and user will not be able to make
calls anyway.

Just a thought... Any comments on this? Is there any reason why
contactlist.xml might be required when XCAP is used?

Regards,
Chris

On 18 August 2011 11:53, Richard Lavoie <lavoie.richard@gmail.com> > wrote:

This might not be a coreect behavior but Jitsi isn't an online service

as all the other services it deals with. Thus there is no global
communication between different running instances, no matter on which
computer they are running.

For this reason, you cannot really synchronize your differents

installations other than sharing the folder that contains the
configuration of jitsi. Even with that folder shared, there will be
problems to update 2 jitsi's instances that are running at the same time.

Maybe you can achieve something with privisionning (not sure if you can

manage contacts with it). But if you can use provisionning, you'll have to
update the configuration by another mean to get the changes reflected in
the provisionning. And the other will probably see the changes on restart.

Richard


#10

На 19.08.11 12:58, Bauersachs Ingo написа:

The simplest workaround (in code) might be to count the number of
contacts inside a meta-contact. If it's only one contact, then we
could use the name that comes from the XCAP server to update the
meta-contact.

Well now that we are discussing this, I am thinking that if the name
changed on the server then it would be safe to assume that the user did
it and that this is their most recent will. If so ... there would be no
reason why they would like to keep using different names for the same
person on other services ... and if they did want to keep them
different, there would be no reason to merge the proto contacts into a
single meta contact.

So I guess the easiest way to implement this would be to always enforce
the same display name for all contacts in a meta contact.

How does this sound?

Emil

···

Ingo

-----Original Message----- From: damencho@damencho.com
[mailto:damencho@damencho.com] On Behalf Of Damian Minkov Sent:
Freitag, 19. August 2011 11:22 To: dev@jitsi.java.net Subject:
[jitsi-dev] Re: XCAP Contact caching Hi,

the local contactlist storage is required cause there are local
settings for the contactlist as there are many protocols and
contacts can be merged, contacts can have common display name. And
this is the reason of the current behavior, cause of the
multi-protocol type of the contact list. If Jitsi is using only
XCAP for storing contacts and no other protocols are available,
using only the serverside list will be reasonable, but when you
merge it with other protocols you got current situation. This are
my thoughts on the subject, correct me if I'm wrong :slight_smile:

Regards damencho

On Fri, Aug 19, 2011 at 11:28 AM, Chris Maciejewski >> <chris@wima.co.uk> wrote:

Indeed Jitsi isn't an online service, but XCAP server (which
Jitsi can use to store contact lists and other presence
information) is a network service that can be accessed by any
number of Jitsi instances and serve as a common synchronisation
tool. (BTW: this is one of the main reasons XCAP was developed in
the first place).

I am thinking if storing contacts locally when XCAP is enabled
is required / needed at all?

Maybe if XCAP is enabled Jitsi shouldn't use contactlist.xml for
SIP contact storage at all? And use exclusively XCAP service
instead? Of course this would mean no access to contact in case
XCAP server is unavailable. But on the other hand in most cases
if XCAP is down, SIP proxy/registrar will be down too and user
will not be able to make calls anyway.

Just a thought... Any comments on this? Is there any reason why
contactlist.xml might be required when XCAP is used?

Regards, Chris

On 18 August 2011 11:53, Richard Lavoie >>> <lavoie.richard@gmail.com> >> wrote:

This might not be a coreect behavior but Jitsi isn't an online
service

as all the other services it deals with. Thus there is no global
communication between different running instances, no matter on
which computer they are running.

For this reason, you cannot really synchronize your differents

installations other than sharing the folder that contains the
configuration of jitsi. Even with that folder shared, there will
be problems to update 2 jitsi's instances that are running at the
same time.

Maybe you can achieve something with privisionning (not sure if
you can

manage contacts with it). But if you can use provisionning, you'll
have to update the configuration by another mean to get the changes
reflected in the provisionning. And the other will probably see the
changes on restart.

Richard

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31