Re: [SyncEvolution] SyncEvolution 1.0 alpha 1: SyncML server, syncs with phone
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
[...]
> 3. When using a "super" datastore, should the user
do
> "syncevolution myphone super" or "syncevolution myphone
>calendar
> todo"? It seems that setting "uri=super" for calendar and
todo
> makes the later possible, but doesn't that lead to duplicate
> entries in the SAN? "syncevolution myphone super" might not work
> because "uri" is not set - is that necessary?
It is expected to be used by:
"syncevolution myphone calendar" to sync with one type or
"syncevolution myphone calendar todo" to sync with both.
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
This will indeed cause duplicate
source alerts in SAN but not failing the phone at the moment.
I can imagine that some phones will get confused by this.
"syncevolution myphone super" is not working. Perhaps we
will also support this?
I find it pretty natural to activate the "super" data source,
considering that this is what is getting synced. We should support it.
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
--
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.