Re: [SyncEvolution] SyncEvolution 1.0 alpha 1: SyncML server, syncs with phone
On Tue, 2009-12-08 at 08:14 +0000, Chen, Congwu wrote:
>
>On Tue, 2009-12-08 at 02:44 +0000, Chen, Congwu wrote:
>> Patrick wrote:
>> >On Thu, 2009-12-03 at 07:03 +0000, Chen, Congwu wrote:
>> >=> http://syncevolution.org/development/sync-phone
>[...]
>Somehow I doubt that "syncevolution myphone calendar" really does sync
>only the events in "calendar". What I expect to happen (please correct
>me if I get this wrong):
> * we add an entry for "calendar" to the SAN which tells the phone
> to sync with "text/x-vcalendar" to "super"
> * phone does that, sending its events and todos
> * our "super" virtual data source is active, likewise syncing both
> "calendar" and "todo" under the hood
Mostly, the "todo" items sent from the server will be rejected by the local
backend.
We are the server, the phone is the client. Do you mean client here?
Care to explain? I don't see why or where the todo items would be
rejected.
And the client will not sending "todo" items too. This
works
effectively as only syncing
"todo" items I think.
Again, I don't see why we would not send "todo" items when the
"super"
data source is active.
>The semantic that we export to the user then becomes:
> * when you have a virtual data source configured, then activating
> any of individual data sources or the virtual data source
> includes all data in the virtual data source in the sync session
> * all of these sources must use the same sync mode
>
I would also like to support syncing only calendar or todo, if my above comments
made sense.
Even if we can get it to work, is it guaranteed that the two peers
remain in sync?
Normally, doing a "syncevolution ... calendar" followed by a
"syncevolution ... todo" has exactly the same effect as a
"syncevolution ... calendar todo".
Not so when the "syncevolution ... calendar" discards changes made to
"todo" that the peer is sending us. We cannot count on the peer sending
us these changes again the next time, even if we reject the changes with
a "temporary" status code.
I had asked Lukas that on the Synthesis mailing list. The Synthesis
engine is smart enough to distinguish between temporary and final status
codes, but a) many servers always sent a 500 status code, regardless
what their problem was and b) clients do not check the exact status
code.
--
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.