[sip-comm-dev] XCAP patches


#1

Hello,

Here I will put the latest patches.

In the attachment you can find xcap-caps fixes during loading (according to
RFC it cannot be null or empty). It fixes the NPE during invalid server URI.

Thanks, Grigorii

xcap-xcapcaps-load.patch (676 Bytes)


#2

Hi Grigorii,

I've committed this patch but there are still some issues, but we
discussed them offline, and I will place them here if anybody is
interested and having a different opinion.
What we were talking is about contactlist synchronization local
against server-side. So we put a property xcap.resolved in the
contacts persistent data so we can distinguish contacts that are
created and resolved against server side list and those who are
created without using xcap.
When we load a few things must happen:

1. Check and if any contact has xcap.resolved=false or is missing such
a property, that contact must be uploaded to server. These are the
contacts that were created prior enabling xcap.

2. Any contacts that are on the server side and are existing locally
are just resolved(contact resolved event is fired) and the property is
set to xcap.resolved=true.

3. Any contact that is missing locally and is on the server side, is
created and the property is set to xcap.resolved=true.

4. Any contact that is xcap.resolved=true and is on our local contact
list but is missing on the server-side must be removed locally.

Personally I was on doubt about the 4. actions, but it seems ok cause
that way we will keep server-side and local contact in synch.
If those steps are ok, they will cover and the situation where we have
an enabled xcap server in our config and for some reason we cannot
connect to the server and we create some local contacts, next time we
can connect to xcap server those contacts will go to server side list.
What I've tested is on a configured account I change the already
working xcap uri so when next time we try to connect and exception
will be thrown, restart account and add a contact. What I think is the
expected behaviour is that the created contact to have a property
xcap.resolved=false, cause we don't have a working connection with the
server and the contact is not stored server-side with xcap. But now
this property is true.

That's all I think. I know most of the stuff we discussed offline and
you are already working on it :), just placing here for the public.

Thank you for you work
damencho

···

On Tue, Aug 24, 2010 at 10:21 AM, Grigorii Balutsel <grigorii.balutsel@gmail.com> wrote:

Hello,

Here I will put the latest patches.

In the attachment you can find xcap-caps fixes during loading (according to
RFC it cannot be null or empty). It fixes the NPE during invalid server URI.

Thanks, Grigorii

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

Hello,

In the attachment you can find the patch that implements listed bellow
behavior.

Thanks, Grigorii

xcap-contacts-resolved.patch (2.68 KB)

···

2010/8/25 Damian Minkov <damencho@sip-communicator.org>

Hi Grigorii,

I've committed this patch but there are still some issues, but we
discussed them offline, and I will place them here if anybody is
interested and having a different opinion.
What we were talking is about contactlist synchronization local
against server-side. So we put a property xcap.resolved in the
contacts persistent data so we can distinguish contacts that are
created and resolved against server side list and those who are
created without using xcap.
When we load a few things must happen:

1. Check and if any contact has xcap.resolved=false or is missing such
a property, that contact must be uploaded to server. These are the
contacts that were created prior enabling xcap.

2. Any contacts that are on the server side and are existing locally
are just resolved(contact resolved event is fired) and the property is
set to xcap.resolved=true.

3. Any contact that is missing locally and is on the server side, is
created and the property is set to xcap.resolved=true.

4. Any contact that is xcap.resolved=true and is on our local contact
list but is missing on the server-side must be removed locally.

Personally I was on doubt about the 4. actions, but it seems ok cause
that way we will keep server-side and local contact in synch.
If those steps are ok, they will cover and the situation where we have
an enabled xcap server in our config and for some reason we cannot
connect to the server and we create some local contacts, next time we
can connect to xcap server those contacts will go to server side list.
What I've tested is on a configured account I change the already
working xcap uri so when next time we try to connect and exception
will be thrown, restart account and add a contact. What I think is the
expected behaviour is that the created contact to have a property
xcap.resolved=false, cause we don't have a working connection with the
server and the contact is not stored server-side with xcap. But now
this property is true.

That's all I think. I know most of the stuff we discussed offline and
you are already working on it :), just placing here for the public.

Thank you for you work
damencho

On Tue, Aug 24, 2010 at 10:21 AM, Grigorii Balutsel > <grigorii.balutsel@gmail.com> wrote:
> Hello,
>
> Here I will put the latest patches.
>
> In the attachment you can find xcap-caps fixes during loading (according
to
> RFC it cannot be null or empty). It fixes the NPE during invalid server
URI.
>
> Thanks, Grigorii
>
> ---------------------------------------------------------------------
> 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,

just one question about the patch. Why you need to set all contacts to
xcap.resolved=false when you are not connected to server. I mean this
part of the patch.

             if (!xCapClient.isConnected() ||
                     !xCapClient.isResourceListsSupported())
             {
+ for(ContactSipImpl contact : getAllContacts(rootGroup))
+ {
+ contact.setXCapResolved(false);
+ }

Thanks
damencho

···

On Thu, Aug 26, 2010 at 5:05 PM, Grigorii Balutsel <grigorii.balutsel@gmail.com> wrote:

Hello,

In the attachment you can find the patch that implements listed bellow
behavior.

Thanks, Grigorii

2010/8/25 Damian Minkov <damencho@sip-communicator.org>

Hi Grigorii,

I've committed this patch but there are still some issues, but we
discussed them offline, and I will place them here if anybody is
interested and having a different opinion.
What we were talking is about contactlist synchronization local
against server-side. So we put a property xcap.resolved in the
contacts persistent data so we can distinguish contacts that are
created and resolved against server side list and those who are
created without using xcap.
When we load a few things must happen:

1. Check and if any contact has xcap.resolved=false or is missing such
a property, that contact must be uploaded to server. These are the
contacts that were created prior enabling xcap.

2. Any contacts that are on the server side and are existing locally
are just resolved(contact resolved event is fired) and the property is
set to xcap.resolved=true.

3. Any contact that is missing locally and is on the server side, is
created and the property is set to xcap.resolved=true.

4. Any contact that is xcap.resolved=true and is on our local contact
list but is missing on the server-side must be removed locally.

Personally I was on doubt about the 4. actions, but it seems ok cause
that way we will keep server-side and local contact in synch.
If those steps are ok, they will cover and the situation where we have
an enabled xcap server in our config and for some reason we cannot
connect to the server and we create some local contacts, next time we
can connect to xcap server those contacts will go to server side list.
What I've tested is on a configured account I change the already
working xcap uri so when next time we try to connect and exception
will be thrown, restart account and add a contact. What I think is the
expected behaviour is that the created contact to have a property
xcap.resolved=false, cause we don't have a working connection with the
server and the contact is not stored server-side with xcap. But now
this property is true.

That's all I think. I know most of the stuff we discussed offline and
you are already working on it :), just placing here for the public.

Thank you for you work
damencho

On Tue, Aug 24, 2010 at 10:21 AM, Grigorii Balutsel >> <grigorii.balutsel@gmail.com> wrote:
> Hello,
>
> Here I will put the latest patches.
>
> In the attachment you can find xcap-caps fixes during loading (according
> to
> RFC it cannot be null or empty). It fixes the NPE during invalid server
> URI.
>
> Thanks, Grigorii
>
> ---------------------------------------------------------------------
> 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


#5

Hi,

You are right, there is no need for it.

Thanks, Grigorii

···

2010/8/26 Damian Minkov <damencho@sip-communicator.org>

Hi,

just one question about the patch. Why you need to set all contacts to
xcap.resolved=false when you are not connected to server. I mean this
part of the patch.

            if (!xCapClient.isConnected() ||
                    !xCapClient.isResourceListsSupported())
            {
+ for(ContactSipImpl contact : getAllContacts(rootGroup))
+ {
+ contact.setXCapResolved(false);
+ }

Thanks
damencho

On Thu, Aug 26, 2010 at 5:05 PM, Grigorii Balutsel > <grigorii.balutsel@gmail.com> wrote:
> Hello,
>
> In the attachment you can find the patch that implements listed bellow
> behavior.
>
> Thanks, Grigorii
>
> 2010/8/25 Damian Minkov <damencho@sip-communicator.org>
>>
>> Hi Grigorii,
>>
>> I've committed this patch but there are still some issues, but we
>> discussed them offline, and I will place them here if anybody is
>> interested and having a different opinion.
>> What we were talking is about contactlist synchronization local
>> against server-side. So we put a property xcap.resolved in the
>> contacts persistent data so we can distinguish contacts that are
>> created and resolved against server side list and those who are
>> created without using xcap.
>> When we load a few things must happen:
>>
>> 1. Check and if any contact has xcap.resolved=false or is missing such
>> a property, that contact must be uploaded to server. These are the
>> contacts that were created prior enabling xcap.
>>
>> 2. Any contacts that are on the server side and are existing locally
>> are just resolved(contact resolved event is fired) and the property is
>> set to xcap.resolved=true.
>>
>> 3. Any contact that is missing locally and is on the server side, is
>> created and the property is set to xcap.resolved=true.
>>
>> 4. Any contact that is xcap.resolved=true and is on our local contact
>> list but is missing on the server-side must be removed locally.
>>
>> Personally I was on doubt about the 4. actions, but it seems ok cause
>> that way we will keep server-side and local contact in synch.
>> If those steps are ok, they will cover and the situation where we have
>> an enabled xcap server in our config and for some reason we cannot
>> connect to the server and we create some local contacts, next time we
>> can connect to xcap server those contacts will go to server side list.
>> What I've tested is on a configured account I change the already
>> working xcap uri so when next time we try to connect and exception
>> will be thrown, restart account and add a contact. What I think is the
>> expected behaviour is that the created contact to have a property
>> xcap.resolved=false, cause we don't have a working connection with the
>> server and the contact is not stored server-side with xcap. But now
>> this property is true.
>>
>> That's all I think. I know most of the stuff we discussed offline and
>> you are already working on it :), just placing here for the public.
>>
>> Thank you for you work
>> damencho
>>
>> On Tue, Aug 24, 2010 at 10:21 AM, Grigorii Balutsel > >> <grigorii.balutsel@gmail.com> wrote:
>> > Hello,
>> >
>> > Here I will put the latest patches.
>> >
>> > In the attachment you can find xcap-caps fixes during loading
(according
>> > to
>> > RFC it cannot be null or empty). It fixes the NPE during invalid
server
>> > URI.
>> >
>> > Thanks, Grigorii
>> >
>> > ---------------------------------------------------------------------
>> > 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


#6

Hi again,

I just tried your patch and I'm afraid its still not working as
expected. Still when there is no connection to xcap server and I add a
contact, the contact is added as xcap.resolved=true. And this way as
the contact is set to be xcap.resolved but its missing on the server,
when we connect again to server on next run the contact is deleted. I
tried and the other scenario where after downloading contactlist I
disabled xcap support and add a contact and I see in its persistent
data its added as xcap.resolved=true but it is not xcap resolved.

Thanks
damencho

···

On Thu, Aug 26, 2010 at 6:29 PM, Grigorii Balutsel <grigorii.balutsel@gmail.com> wrote:

Hi,

You are right, there is no need for it.

Thanks, Grigorii

2010/8/26 Damian Minkov <damencho@sip-communicator.org>

Hi,

just one question about the patch. Why you need to set all contacts to
xcap.resolved=false when you are not connected to server. I mean this
part of the patch.

        if \(\!xCapClient\.isConnected\(\) ||
                \!xCapClient\.isResourceListsSupported\(\)\)
        \{

+ for(ContactSipImpl contact : getAllContacts(rootGroup))
+ {
+ contact.setXCapResolved(false);
+ }

Thanks
damencho

On Thu, Aug 26, 2010 at 5:05 PM, Grigorii Balutsel >> <grigorii.balutsel@gmail.com> wrote:
> Hello,
>
> In the attachment you can find the patch that implements listed bellow
> behavior.
>
> Thanks, Grigorii
>
> 2010/8/25 Damian Minkov <damencho@sip-communicator.org>
>>
>> Hi Grigorii,
>>
>> I've committed this patch but there are still some issues, but we
>> discussed them offline, and I will place them here if anybody is
>> interested and having a different opinion.
>> What we were talking is about contactlist synchronization local
>> against server-side. So we put a property xcap.resolved in the
>> contacts persistent data so we can distinguish contacts that are
>> created and resolved against server side list and those who are
>> created without using xcap.
>> When we load a few things must happen:
>>
>> 1. Check and if any contact has xcap.resolved=false or is missing such
>> a property, that contact must be uploaded to server. These are the
>> contacts that were created prior enabling xcap.
>>
>> 2. Any contacts that are on the server side and are existing locally
>> are just resolved(contact resolved event is fired) and the property is
>> set to xcap.resolved=true.
>>
>> 3. Any contact that is missing locally and is on the server side, is
>> created and the property is set to xcap.resolved=true.
>>
>> 4. Any contact that is xcap.resolved=true and is on our local contact
>> list but is missing on the server-side must be removed locally.
>>
>> Personally I was on doubt about the 4. actions, but it seems ok cause
>> that way we will keep server-side and local contact in synch.
>> If those steps are ok, they will cover and the situation where we have
>> an enabled xcap server in our config and for some reason we cannot
>> connect to the server and we create some local contacts, next time we
>> can connect to xcap server those contacts will go to server side list.
>> What I've tested is on a configured account I change the already
>> working xcap uri so when next time we try to connect and exception
>> will be thrown, restart account and add a contact. What I think is the
>> expected behaviour is that the created contact to have a property
>> xcap.resolved=false, cause we don't have a working connection with the
>> server and the contact is not stored server-side with xcap. But now
>> this property is true.
>>
>> That's all I think. I know most of the stuff we discussed offline and
>> you are already working on it :), just placing here for the public.
>>
>> Thank you for you work
>> damencho
>>
>> On Tue, Aug 24, 2010 at 10:21 AM, Grigorii Balutsel >> >> <grigorii.balutsel@gmail.com> wrote:
>> > Hello,
>> >
>> > Here I will put the latest patches.
>> >
>> > In the attachment you can find xcap-caps fixes during loading
>> > (according
>> > to
>> > RFC it cannot be null or empty). It fixes the NPE during invalid
>> > server
>> > URI.
>> >
>> > Thanks, Grigorii
>> >
>> > ---------------------------------------------------------------------
>> > 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

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


#7

Hello,

In the attachment you can find the patch that will fix that problem.

Thanks Grigorii

xcap-contacts-resolved.patch (2.85 KB)

···

2010/8/27 Damian Minkov <damencho@sip-communicator.org>

Hi again,

I just tried your patch and I'm afraid its still not working as
expected. Still when there is no connection to xcap server and I add a
contact, the contact is added as xcap.resolved=true. And this way as
the contact is set to be xcap.resolved but its missing on the server,
when we connect again to server on next run the contact is deleted. I
tried and the other scenario where after downloading contactlist I
disabled xcap support and add a contact and I see in its persistent
data its added as xcap.resolved=true but it is not xcap resolved.

Thanks
damencho

On Thu, Aug 26, 2010 at 6:29 PM, Grigorii Balutsel > <grigorii.balutsel@gmail.com> wrote:
> Hi,
>
> You are right, there is no need for it.
>
> Thanks, Grigorii
>
> 2010/8/26 Damian Minkov <damencho@sip-communicator.org>
>>
>> Hi,
>>
>> just one question about the patch. Why you need to set all contacts to
>> xcap.resolved=false when you are not connected to server. I mean this
>> part of the patch.
>>
>> if (!xCapClient.isConnected() ||
>> !xCapClient.isResourceListsSupported())
>> {
>> + for(ContactSipImpl contact : getAllContacts(rootGroup))
>> + {
>> + contact.setXCapResolved(false);
>> + }
>>
>>
>> Thanks
>> damencho
>>
>> On Thu, Aug 26, 2010 at 5:05 PM, Grigorii Balutsel > >> <grigorii.balutsel@gmail.com> wrote:
>> > Hello,
>> >
>> > In the attachment you can find the patch that implements listed bellow
>> > behavior.
>> >
>> > Thanks, Grigorii
>> >
>> > 2010/8/25 Damian Minkov <damencho@sip-communicator.org>
>> >>
>> >> Hi Grigorii,
>> >>
>> >> I've committed this patch but there are still some issues, but we
>> >> discussed them offline, and I will place them here if anybody is
>> >> interested and having a different opinion.
>> >> What we were talking is about contactlist synchronization local
>> >> against server-side. So we put a property xcap.resolved in the
>> >> contacts persistent data so we can distinguish contacts that are
>> >> created and resolved against server side list and those who are
>> >> created without using xcap.
>> >> When we load a few things must happen:
>> >>
>> >> 1. Check and if any contact has xcap.resolved=false or is missing
such
>> >> a property, that contact must be uploaded to server. These are the
>> >> contacts that were created prior enabling xcap.
>> >>
>> >> 2. Any contacts that are on the server side and are existing locally
>> >> are just resolved(contact resolved event is fired) and the property
is
>> >> set to xcap.resolved=true.
>> >>
>> >> 3. Any contact that is missing locally and is on the server side, is
>> >> created and the property is set to xcap.resolved=true.
>> >>
>> >> 4. Any contact that is xcap.resolved=true and is on our local contact
>> >> list but is missing on the server-side must be removed locally.
>> >>
>> >> Personally I was on doubt about the 4. actions, but it seems ok cause
>> >> that way we will keep server-side and local contact in synch.
>> >> If those steps are ok, they will cover and the situation where we
have
>> >> an enabled xcap server in our config and for some reason we cannot
>> >> connect to the server and we create some local contacts, next time we
>> >> can connect to xcap server those contacts will go to server side
list.
>> >> What I've tested is on a configured account I change the already
>> >> working xcap uri so when next time we try to connect and exception
>> >> will be thrown, restart account and add a contact. What I think is
the
>> >> expected behaviour is that the created contact to have a property
>> >> xcap.resolved=false, cause we don't have a working connection with
the
>> >> server and the contact is not stored server-side with xcap. But now
>> >> this property is true.
>> >>
>> >> That's all I think. I know most of the stuff we discussed offline and
>> >> you are already working on it :), just placing here for the public.
>> >>
>> >> Thank you for you work
>> >> damencho
>> >>
>> >> On Tue, Aug 24, 2010 at 10:21 AM, Grigorii Balutsel > >> >> <grigorii.balutsel@gmail.com> wrote:
>> >> > Hello,
>> >> >
>> >> > Here I will put the latest patches.
>> >> >
>> >> > In the attachment you can find xcap-caps fixes during loading
>> >> > (according
>> >> > to
>> >> > RFC it cannot be null or empty). It fixes the NPE during invalid
>> >> > server
>> >> > URI.
>> >> >
>> >> > Thanks, Grigorii
>> >> >
>> >> >
---------------------------------------------------------------------
>> >> > 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
>>
>
>

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


#8

Hi,

I think all known issues are resolved and everything is committed with r7647.

Thanks
damencho

···

On Fri, Aug 27, 2010 at 10:24 AM, Grigorii Balutsel <grigorii.balutsel@gmail.com> wrote:

Hello,

In the attachment you can find the patch that will fix that problem.

Thanks Grigorii

2010/8/27 Damian Minkov <damencho@sip-communicator.org>

Hi again,

I just tried your patch and I'm afraid its still not working as
expected. Still when there is no connection to xcap server and I add a
contact, the contact is added as xcap.resolved=true. And this way as
the contact is set to be xcap.resolved but its missing on the server,
when we connect again to server on next run the contact is deleted. I
tried and the other scenario where after downloading contactlist I
disabled xcap support and add a contact and I see in its persistent
data its added as xcap.resolved=true but it is not xcap resolved.

Thanks
damencho

On Thu, Aug 26, 2010 at 6:29 PM, Grigorii Balutsel >> <grigorii.balutsel@gmail.com> wrote:
> Hi,
>
> You are right, there is no need for it.
>
> Thanks, Grigorii
>
> 2010/8/26 Damian Minkov <damencho@sip-communicator.org>
>>
>> Hi,
>>
>> just one question about the patch. Why you need to set all contacts to
>> xcap.resolved=false when you are not connected to server. I mean this
>> part of the patch.
>>
>> if (!xCapClient.isConnected() ||
>> !xCapClient.isResourceListsSupported())
>> {
>> + for(ContactSipImpl contact :
>> getAllContacts(rootGroup))
>> + {
>> + contact.setXCapResolved(false);
>> + }
>>
>>
>> Thanks
>> damencho
>>
>> On Thu, Aug 26, 2010 at 5:05 PM, Grigorii Balutsel >> >> <grigorii.balutsel@gmail.com> wrote:
>> > Hello,
>> >
>> > In the attachment you can find the patch that implements listed
>> > bellow
>> > behavior.
>> >
>> > Thanks, Grigorii
>> >
>> > 2010/8/25 Damian Minkov <damencho@sip-communicator.org>
>> >>
>> >> Hi Grigorii,
>> >>
>> >> I've committed this patch but there are still some issues, but we
>> >> discussed them offline, and I will place them here if anybody is
>> >> interested and having a different opinion.
>> >> What we were talking is about contactlist synchronization local
>> >> against server-side. So we put a property xcap.resolved in the
>> >> contacts persistent data so we can distinguish contacts that are
>> >> created and resolved against server side list and those who are
>> >> created without using xcap.
>> >> When we load a few things must happen:
>> >>
>> >> 1. Check and if any contact has xcap.resolved=false or is missing
>> >> such
>> >> a property, that contact must be uploaded to server. These are the
>> >> contacts that were created prior enabling xcap.
>> >>
>> >> 2. Any contacts that are on the server side and are existing locally
>> >> are just resolved(contact resolved event is fired) and the property
>> >> is
>> >> set to xcap.resolved=true.
>> >>
>> >> 3. Any contact that is missing locally and is on the server side, is
>> >> created and the property is set to xcap.resolved=true.
>> >>
>> >> 4. Any contact that is xcap.resolved=true and is on our local
>> >> contact
>> >> list but is missing on the server-side must be removed locally.
>> >>
>> >> Personally I was on doubt about the 4. actions, but it seems ok
>> >> cause
>> >> that way we will keep server-side and local contact in synch.
>> >> If those steps are ok, they will cover and the situation where we
>> >> have
>> >> an enabled xcap server in our config and for some reason we cannot
>> >> connect to the server and we create some local contacts, next time
>> >> we
>> >> can connect to xcap server those contacts will go to server side
>> >> list.
>> >> What I've tested is on a configured account I change the already
>> >> working xcap uri so when next time we try to connect and exception
>> >> will be thrown, restart account and add a contact. What I think is
>> >> the
>> >> expected behaviour is that the created contact to have a property
>> >> xcap.resolved=false, cause we don't have a working connection with
>> >> the
>> >> server and the contact is not stored server-side with xcap. But now
>> >> this property is true.
>> >>
>> >> That's all I think. I know most of the stuff we discussed offline
>> >> and
>> >> you are already working on it :), just placing here for the public.
>> >>
>> >> Thank you for you work
>> >> damencho
>> >>
>> >> On Tue, Aug 24, 2010 at 10:21 AM, Grigorii Balutsel >> >> >> <grigorii.balutsel@gmail.com> wrote:
>> >> > Hello,
>> >> >
>> >> > Here I will put the latest patches.
>> >> >
>> >> > In the attachment you can find xcap-caps fixes during loading
>> >> > (according
>> >> > to
>> >> > RFC it cannot be null or empty). It fixes the NPE during invalid
>> >> > server
>> >> > URI.
>> >> >
>> >> > Thanks, Grigorii
>> >> >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > 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
>>
>
>

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