5:20 a.m.
Hi All,
Need some input regarding devinf being exchanged between syncevo as
client and another server.
I have a set of devinf for multiple types of devices using which i
need to communicate with the Server.
How can i force the devinf in the messages being sent from syncevo client?
Cheers
5:31 a.m.
On Mi, 2013-11-20 at 17:50 +0530, Sachin Gupta wrote:
Hi All,
Need some input regarding devinf being exchanged between syncevo as
client and another server.
I have a set of devinf for multiple types of devices using which i
need to communicate with the Server.
How can i force the devinf in the messages being sent from syncevo client?
If I understand you right, you want to have SyncEvolution sent the
DevInf of some other client?
That is not possible. SyncEvolution, or rather the libsynthesis that it
uses, generates the content of DevInf dynamically based on things like
the datatype configuration. This cannot be overridden.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
5:39 a.m.
Hi Patrick,
I installed syncevo on a debian machine and tested with a SyncML Server.
This not being a specific client, it still generated a devinf file
which was sent to the server.
In this case how is the devinf being generated? Is this generation
being done via libsynthesis or syncevo code?
Cheers
On Wed, Nov 20, 2013 at 6:01 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mi, 2013-11-20 at 17:50 +0530, Sachin Gupta wrote:
> Hi All,
>
> Need some input regarding devinf being exchanged between syncevo as
> client and another server.
>
> I have a set of devinf for multiple types of devices using which i
> need to communicate with the Server.
>
> How can i force the devinf in the messages being sent from syncevo client?
If I understand you right, you want to have SyncEvolution sent the
DevInf of some other client?
That is not possible. SyncEvolution, or rather the libsynthesis that it
uses, generates the content of DevInf dynamically based on things like
the datatype configuration. This cannot be overridden.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
6:06 a.m.
I am sure some code hook needs to be put in place in either syncevo
code or libsynthesis.
But wasnt sure how and where to do this.
Request some inputs for this.
I need to develop a test suite kind of application where the input
would be a set of devinfo's of various OEMs.
Cheers
On Wed, Nov 20, 2013 at 6:09 PM, Sachin Gupta <chingupt(a)gmail.com> wrote:
Hi Patrick,
I installed syncevo on a debian machine and tested with a SyncML Server.
This not being a specific client, it still generated a devinf file
which was sent to the server.
In this case how is the devinf being generated? Is this generation
being done via libsynthesis or syncevo code?
Cheers
On Wed, Nov 20, 2013 at 6:01 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> On Mi, 2013-11-20 at 17:50 +0530, Sachin Gupta wrote:
>> Hi All,
>>
>> Need some input regarding devinf being exchanged between syncevo as
>> client and another server.
>>
>> I have a set of devinf for multiple types of devices using which i
>> need to communicate with the Server.
>>
>> How can i force the devinf in the messages being sent from syncevo client?
>
> If I understand you right, you want to have SyncEvolution sent the
> DevInf of some other client?
>
> That is not possible. SyncEvolution, or rather the libsynthesis that it
> uses, generates the content of DevInf dynamically based on things like
> the datatype configuration. This cannot be overridden.
>
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>
>
7:06 a.m.
On Mi, 2013-11-20 at 18:36 +0530, Sachin Gupta wrote:
I am sure some code hook needs to be put in place in either syncevo
code or libsynthesis.
But wasnt sure how and where to do this.
Some things, like product and vendor, are set by SyncEvolution. See
SyncContext::getConfigXML() and calls like substTag(xml, "model",
getMod());
The CtCap content is derived from the datatype definitions
in /usr/share/syncevolution/xml/datatypes/
I need to develop a test suite kind of application where the input
would be a set of devinfo's of various OEMs.
I'm still not sure what you want to achieve and what you expect to
modify in the DevInf sent by SyncEvolution.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
10:28 a.m.
Thanks patrick,
I need to develop a test suite which takes in a set of devinf fiiles and
runs somes test cases. Please advise how this can be achieved with a remote
server and syncevo as a client.
For the same reason was thinking on haxking the devinf.
Ps. Please excuse the typos.
Regards
10:36 a.m.
On Mi, 2013-11-20 at 22:58 +0530, Sachin Gupta wrote:
Thanks patrick,
I need to develop a test suite which takes in a set of devinf fiiles
and runs somes test cases. Please advise how this can be achieved with
a remote server and syncevo as a client.
I doubt that it can be done with the current code unless you completely
rip it apart and build something new.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
11:21 p.m.
Hi Patrick,
A query.
In the folder /usr/share/syncevolution i found a file 02google-contacts.xml
What is this file used for? In a sample exchange between client and
server, i found the xml being dumped which seemed to be the same as
this one.
But the xmls being dumped were different.
Also, This has a tag "overridedevinf". Is this for overriding the
devinf information in the xml above?
Regards
On Wed, Nov 20, 2013 at 11:06 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mi, 2013-11-20 at 22:58 +0530, Sachin Gupta wrote:
> Thanks patrick,
>
> I need to develop a test suite which takes in a set of devinf fiiles
> and runs somes test cases. Please advise how this can be achieved with
> a remote server and syncevo as a client.
I doubt that it can be done with the current code unless you completely
rip it apart and build something new.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
1:05 a.m.
On Do, 2013-11-21 at 11:51 +0530, Sachin Gupta wrote:
Hi Patrick,
A query.
In the folder /usr/share/syncevolution i found a file 02google-contacts.xml
What is this file used for? In a sample exchange between client and
server, i found the xml being dumped which seemed to be the same as
this one.
But the xmls being dumped were different.
Also, This has a tag "overridedevinf". Is this for overriding the
devinf information in the xml above?
It does the reverse of what you want to do (at least as far as I
understand it): Google's SyncML server did not include CtCap information
in its DevInf. The 02google-contacts.xml adds that information by
hard-coding it on the client side. In other words, you can feed
arbitrary DevInf for the server into a SyncEvolution client, but you
cannot make the client send different DevInf.
From the commits:
commit 17337d46ce299846335a26041199459cac95cdc0
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Wed Jun 15 15:55:59 2011 +0200
Google Contacts: add CtCap information (BMC #15029)
The CtCap information is necessary for preserving fields not supported
by the Google SyncML server. It depends on the "overridedevinf"
patches for libsynthesis, currently under review.
commit 62df728b87da358b497696ced0500ff221ea0979
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Wed Jun 15 12:24:17 2011 +0200
remote rules: added OverrideDevInf
Many SyncML servers send DevInf without CtCap inside. For those
servers, the engine (often incorrectly) has to assume that they
support all fields.
This patch adds a configuration element "OverrideDevInf" which helps
to address this problem. It may occur in a "RemoteRule". Once that
rule matches a DevInf sent by a peer, processing of CtCap continues
with the CtCap element of the DevInf inside the remote rule. This
allows adding and overriding the CtCap from a peer.
"OverrideDevInf" must contain a complete DevInf, although right now
only the CtCap inside it really matters.
This approach has the advantage that it can reuse the existing and
somewhat documented CtCap format for describing capabilities. The
downside is that not everything can be encoded in that format, for example,
how many components of the ORG field are supported. A possible
solution for that is to extend the format in a way that only the Synthesis
engine understand and/or standardize such extensions.
Right now the "OverrideDevInf" content is only parsed when needed.
Beware that syntax errors will only be found when using the rule!
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
midnight
Thanks Patrick,
I guess this is also not useful for me :(
I am a bit confused. Is the DevInf prepared by the libsynthesis engine
or the Syncevo client?
From code, It seems that the libsynthesis engine does that. Still
wanted to confirm this.
But if the client is running on a Linux OS or Non Mobile platform, how
are the device capabilities decided? On Linux Debian machine there are
no contacts or calenders to be synced, so are the capabilities
hardcoded ?
I believe, that the client sends its own capabilities to the server in
the first few exchanges and server then sends it capabilities. So
client has to prepare its devinf somehow.
Please guide.
Regards
On Thu, Nov 21, 2013 at 1:35 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Do, 2013-11-21 at 11:51 +0530, Sachin Gupta wrote:
> Hi Patrick,
>
> A query.
> In the folder /usr/share/syncevolution i found a file 02google-contacts.xml
> What is this file used for? In a sample exchange between client and
> server, i found the xml being dumped which seemed to be the same as
> this one.
> But the xmls being dumped were different.
>
> Also, This has a tag "overridedevinf". Is this for overriding the
> devinf information in the xml above?
It does the reverse of what you want to do (at least as far as I
understand it): Google's SyncML server did not include CtCap information
in its DevInf. The 02google-contacts.xml adds that information by
hard-coding it on the client side. In other words, you can feed
arbitrary DevInf for the server into a SyncEvolution client, but you
cannot make the client send different DevInf.
From the commits:
commit 17337d46ce299846335a26041199459cac95cdc0
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Wed Jun 15 15:55:59 2011 +0200
Google Contacts: add CtCap information (BMC #15029)
The CtCap information is necessary for preserving fields not supported
by the Google SyncML server. It depends on the "overridedevinf"
patches for libsynthesis, currently under review.
commit 62df728b87da358b497696ced0500ff221ea0979
Author: Patrick Ohly <patrick.ohly(a)intel.com>
Date: Wed Jun 15 12:24:17 2011 +0200
remote rules: added OverrideDevInf
Many SyncML servers send DevInf without CtCap inside. For those
servers, the engine (often incorrectly) has to assume that they
support all fields.
This patch adds a configuration element "OverrideDevInf" which helps
to address this problem. It may occur in a "RemoteRule". Once that
rule matches a DevInf sent by a peer, processing of CtCap continues
with the CtCap element of the DevInf inside the remote rule. This
allows adding and overriding the CtCap from a peer.
"OverrideDevInf" must contain a complete DevInf, although right now
only the CtCap inside it really matters.
This approach has the advantage that it can reuse the existing and
somewhat documented CtCap format for describing capabilities. The
downside is that not everything can be encoded in that format, for example,
how many components of the ORG field are supported. A possible
solution for that is to extend the format in a way that only the Synthesis
engine understand and/or standardize such extensions.
Right now the "OverrideDevInf" content is only parsed when needed.
Beware that syntax errors will only be found when using the rule!
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
12:38 a.m.
On Fr, 2013-11-22 at 12:30 +0530, Sachin Gupta wrote:
Thanks Patrick,
I guess this is also not useful for me :(
I am a bit confused. Is the DevInf prepared by the libsynthesis engine
or the Syncevo client?
Synthesis engine, with input from SyncEvolution.
But if the client is running on a Linux OS or Non Mobile platform,
how
are the device capabilities decided? On Linux Debian machine there are
no contacts or calenders to be synced, so are the capabilities
hardcoded ?
SyncEvolution enables sources and defines the datatype for each source.
That's what the Synthesis engine then turns into the CtCap.
Other capabilities, like amount of memory, are either hard-coded or not
used at all.
I believe, that the client sends its own capabilities to the server
in
the first few exchanges and server then sends it capabilities. So
client has to prepare its devinf somehow.
Correct. DevInf from client and server are unrelated.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
12:52 a.m.
Hi,
Can you point me to the code piece where Syncevo prepares and provides
the input to synthesis.
Please elaborate more on Source which Syncevo enables. What are these
and how are these enabled?
Regards
On Fri, Nov 22, 2013 at 1:08 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Fr, 2013-11-22 at 12:30 +0530, Sachin Gupta wrote:
> Thanks Patrick,
>
> I guess this is also not useful for me :(
>
> I am a bit confused. Is the DevInf prepared by the libsynthesis engine
> or the Syncevo client?
Synthesis engine, with input from SyncEvolution.
> But if the client is running on a Linux OS or Non Mobile platform, how
> are the device capabilities decided? On Linux Debian machine there are
> no contacts or calenders to be synced, so are the capabilities
> hardcoded ?
SyncEvolution enables sources and defines the datatype for each source.
That's what the Synthesis engine then turns into the CtCap.
Other capabilities, like amount of memory, are either hard-coded or not
used at all.
> I believe, that the client sends its own capabilities to the server in
> the first few exchanges and server then sends it capabilities. So
> client has to prepare its devinf somehow.
Correct. DevInf from client and server are unrelated.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
1:38 a.m.
On Fr, 2013-11-22 at 13:22 +0530, Sachin Gupta wrote:
Hi,
Can you point me to the code piece where Syncevo prepares and provides
the input to synthesis.
Please elaborate more on Source which Syncevo enables. What are these
and how are these enabled?
Have you read the libsynthesis/doc/SySync_config_reference.pdf and
SDK_manual.pdf? This explains all options offered by the Synthesis
engine. Once you know what to look for, just grep the SyncEvolution
source code, for example:
git grep -i "<datastore"
...
src/syncevo/SyncContext.cpp: datastores << " <datastore
name='" << name << "' type='plugin'>\n"
<<
...
There's also this introduction:
https://syncevolution.org/development/pim-data-synchronization-why-it-so-...
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
12:14 a.m.
Hello Patrick,
Somehow i was able to modify the devinf information being sent from
client to remote Server.
Had to hack the libsynthesis code for this. Though the engine still
dumps the original devinf in outgoing.xml, server gets the modified
devinf.
I modified the syncagent.cpp of libsynthesis code in function
TSyncAgent::NextMessage just before it enters FinishMessage and
replace the already formed DevInf information.
Sync happened with the modified devinf, but am not sure what are the
repurcussions of modifiying the devinf in memory on client side. How
will the client behave to syncs sent from server?
Can you think/suggest some issues or cases which i can test this change?
Regards
On Fri, Nov 22, 2013 at 2:08 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Fr, 2013-11-22 at 13:22 +0530, Sachin Gupta wrote:
> Hi,
>
> Can you point me to the code piece where Syncevo prepares and provides
> the input to synthesis.
>
> Please elaborate more on Source which Syncevo enables. What are these
> and how are these enabled?
Have you read the libsynthesis/doc/SySync_config_reference.pdf and
SDK_manual.pdf? This explains all options offered by the Synthesis
engine. Once you know what to look for, just grep the SyncEvolution
source code, for example:
git grep -i "<datastore"
...
src/syncevo/SyncContext.cpp: datastores << " <datastore
name='" << name << "' type='plugin'>\n"
<<
...
There's also this introduction:
https://syncevolution.org/development/pim-data-synchronization-why-it-so-...
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
12:38 a.m.
On Wed, 2013-11-27 at 12:44 +0530, Sachin Gupta wrote:
Somehow i was able to modify the devinf information being sent from
client to remote Server.
Had to hack the libsynthesis code for this. Though the engine still
dumps the original devinf in outgoing.xml, server gets the modified
devinf.
I modified the syncagent.cpp of libsynthesis code in function
TSyncAgent::NextMessage just before it enters FinishMessage and
replace the already formed DevInf information.
Yes, low-level hacking of course always is an option. It's just software
after all ;-}
Sync happened with the modified devinf, but am not sure what are the
repurcussions of modifiying the devinf in memory on client side. How
will the client behave to syncs sent from server?
It depends on whether the server uses the sent DevInf at all.
The Synthesis server definitely does. If the client claims to not
support, say, ADR, then the client cannot remove that piece of
information on the server because the server will always keep the data
intact during updates.
If I remember correctly, the Funambol server only checked the PHOTO
entry. It only sent photos if that was present, at least with some
phones. Better ask Funambol.
I don't know about other servers.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
1:53 a.m.
Thanks Patrick.
"It depends on whether the server uses the sent DevInf at all". This
statement helped a lot :)
You were right!. Funambol is not considering the device capabilities.
I tested by removing the TEL property from client devinf, but still
Funambol did not take this into consideration and as part of the
refresh-from-server, Funambol sent the complete TEL information.
I will now try deploying syncevo as a server and try synncing with this.
T&R
Sachin
On Wed, Nov 27, 2013 at 1:08 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Wed, 2013-11-27 at 12:44 +0530, Sachin Gupta wrote:
> Somehow i was able to modify the devinf information being sent from
> client to remote Server.
> Had to hack the libsynthesis code for this. Though the engine still
> dumps the original devinf in outgoing.xml, server gets the modified
> devinf.
>
> I modified the syncagent.cpp of libsynthesis code in function
> TSyncAgent::NextMessage just before it enters FinishMessage and
> replace the already formed DevInf information.
Yes, low-level hacking of course always is an option. It's just software
after all ;-}
> Sync happened with the modified devinf, but am not sure what are the
> repurcussions of modifiying the devinf in memory on client side. How
> will the client behave to syncs sent from server?
It depends on whether the server uses the sent DevInf at all.
The Synthesis server definitely does. If the client claims to not
support, say, ADR, then the client cannot remove that piece of
information on the server because the server will always keep the data
intact during updates.
If I remember correctly, the Funambol server only checked the PHOTO
entry. It only sent photos if that was present, at least with some
phones. Better ask Funambol.
I don't know about other servers.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
2:01 a.m.
On Thu, 2013-11-28 at 14:23 +0530, Sachin Gupta wrote:
Thanks Patrick.
"It depends on whether the server uses the sent DevInf at all". This
statement helped a lot :)
You were right!. Funambol is not considering the device capabilities.
I tested by removing the TEL property from client devinf, but still
Funambol did not take this into consideration and as part of the
refresh-from-server, Funambol sent the complete TEL information.
That alone might not be enough to determine whether the info is used.
Even if the client does not support a property, the server might still
send it, just to be sure, at least when the property is small.
A better test looks at how the server reacts when receiving an update
where a property is missing that the server currently has: if the client
supports the property, the server should remove its copy of the
property. If the client doesn't, the server should keep its copy.
I will now try deploying syncevo as a server and try synncing with
this.
https://syncevolution.org/wiki/http-server-howto
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
4:26 a.m.
Hi Patrick,
Not able to understand this clearly:
"A better test looks at how the server reacts when receiving an update
where a property is missing that the server currently has: if the
client
supports the property, the server should remove its copy of the
property. If the client doesn't, the server should keep its copy."
If for e.g. TEL property is supported by server but not client, then
server should remove these fields from its copy? This doesnt look
right to me. What of the other client does support this? In this case
the TEL information will be lost.
I ran some test cases:
1. Client DevInf does not support the TEL Property where as the Server
does. TEL entries from vcard also removed. Did a sync.
[INFO] addressbook: starting normal sync, two-way (peer is server)
[INFO] creating complete data backup of source addressbook before sync (enabled
Local data changes to be applied during synchronization:
*** addressbook ***
after last sync | current data
removed since last sync <
added since last sync
-------------------------------------------------------------------------------
BEGIN:VCARD BEGIN:VCARD
N:aab1;sa1 N:aab1;sa1
FN:aa\, sa FN:aa\, sa
TEL;TYPE=CELL:8 <
TEL;TYPE=FAX;TYPE=HOME:7 <
TEL;TYPE=HOME:9899 <
TEL;TYPE=WORK:9 <
VERSION:3.0 VERSION:3.0
END:VCARD END:VCARD
-------------------------------------------------------------------------------
[INFO] addressbook: sent 1/1
[INFO] addressbook: started
[INFO] addressbook: normal sync done successfully
[INFO] creating complete data backup after sync (enabled with dumpData and neede
Synchronization successful.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 0 |
| two-way, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 2 before sync, 2 after it |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Thu Nov 28 04:24:45 2013, duration 0:02min |
| synchronization completed successfully |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
2. Just after that i did a refresh from server.
Local data changes to be applied during synchronization:
*** addressbook ***
no changes
[INFO] addressbook: deleting 0
[INFO] addressbook: deleting 1/2
[INFO] addressbook: deleting 2/2
[INFO] addressbook: started
[INFO] addressbook: received 1/2
[INFO] addressbook: added 1, updated 0, removed 0
[INFO] addressbook: received 2/2
[INFO] addressbook: added 2, updated 0, removed 0
[INFO] addressbook: first time sync done successfully
[INFO] creating complete data backup after sync (enabled with dumpData and neede
Synchronization successful.
Changes applied during synchronization:
+---------------|-----------------------|-----------------------|-CON-+
| | LOCAL | REMOTE | FLI |
| Source | NEW | MOD | DEL | ERR | NEW | MOD | DEL | ERR | CTS |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| addressbook | 2 | 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 |
| refresh-from-remote, 0 KB sent by client, 0 KB received |
| item(s) in database backup: 2 before sync, 2 after it |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| start Thu Nov 28 04:29:10 2013, duration 0:04min |
| synchronization completed successfully |
+---------------+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Data modified locally during synchronization:
*** addressbook ***
before sync | after sync
removed during sync <
added during sync
-------------------------------------------------------------------------------
BEGIN:VCARD BEGIN:VCARD
N:aab1;sa1 N:aab1;sa1
FN:aa\, sa FN:aa\, sa
TEL;TYPE=CELL:8
TEL;TYPE=FAX;TYPE=HOME:7
TEL;TYPE=HOME:9899
TEL;TYPE=WORK:9
VERSION:3.0 VERSION:3.0
END:VCARD END:VCARD
-------------------------------------------------------------------------------
===============================================================
The TEL property fields are back. I checked the server, the fields
were present. Not removed from the server.
It seems that the Funambol does not take client capabilities into consideration.
Regards
On Thu, Nov 28, 2013 at 2:31 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Thu, 2013-11-28 at 14:23 +0530, Sachin Gupta wrote:
> Thanks Patrick.
>
> "It depends on whether the server uses the sent DevInf at all". This
> statement helped a lot :)
>
> You were right!. Funambol is not considering the device capabilities.
> I tested by removing the TEL property from client devinf, but still
> Funambol did not take this into consideration and as part of the
> refresh-from-server, Funambol sent the complete TEL information.
That alone might not be enough to determine whether the info is used.
Even if the client does not support a property, the server might still
send it, just to be sure, at least when the property is small.
A better test looks at how the server reacts when receiving an update
where a property is missing that the server currently has: if the client
supports the property, the server should remove its copy of the
property. If the client doesn't, the server should keep its copy.
> I will now try deploying syncevo as a server and try synncing with this.
https://syncevolution.org/wiki/http-server-howto
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
5:49 a.m.
On Thu, 2013-11-28 at 16:56 +0530, Sachin Gupta wrote:
Hi Patrick,
Not able to understand this clearly:
"A better test looks at how the server reacts when receiving an update
where a property is missing that the server currently has: if the
client
supports the property, the server should remove its copy of the
property. If the client doesn't, the server should keep its copy."
If for e.g. TEL property is supported by server but not client, then
server should remove these fields from its copy?
No.
I'm talking about this sequence of events:
Server sends to client a new contact:
N:foo
TEL:1243
In the next sync, the client sends back:
N:foo
ADR:abcd
What should the server now store?
Option 1 (client did not send back TEL because it doesn't support it):
N:foo
TEL:1234
ADR:abcd
Option 2 (client supports TEL, user removed TEL on client):
N:foo
ADR:abcd
CtCap provides the information to the server to distinguish between
these two cases. Without it, the server has to guess or somehow know
about the client.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
10:06 p.m.
Ok. Think i got it. But what about the case i mentioned. Is the behaviour
correct in this case?
Regards
On Nov 28, 2013 6:19 PM, "Patrick Ohly" <patrick.ohly(a)intel.com> wrote:
On Thu, 2013-11-28 at 16:56 +0530, Sachin Gupta wrote:
> Hi Patrick,
>
> Not able to understand this clearly:
> "A better test looks at how the server reacts when receiving an update
> where a property is missing that the server currently has: if the
> client
> supports the property, the server should remove its copy of the
> property. If the client doesn't, the server should keep its copy."
>
> If for e.g. TEL property is supported by server but not client, then
> server should remove these fields from its copy?
No.
I'm talking about this sequence of events:
Server sends to client a new contact:
N:foo
TEL:1243
In the next sync, the client sends back:
N:foo
ADR:abcd
What should the server now store?
Option 1 (client did not send back TEL because it doesn't support it):
N:foo
TEL:1234
ADR:abcd
Option 2 (client supports TEL, user removed TEL on client):
N:foo
ADR:abcd
CtCap provides the information to the server to distinguish between
these two cases. Without it, the server has to guess or somehow know
about the client.
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.
3134
days inactive
3143
days old
syncevolution@synevolution.org
19 comments
2 participants
participants (2)
-
Patrick Ohly -
Sachin Gupta