--- Begin Message ---
Hello,
While I am tesing vcal1.0 format, I found it is nearly impossible to
compare a vcalendar 1.0 item and a icalendar 2.0 item.
The root cause is, we always tell Synthesis to transform its data as
"icalendar 2.0" before storing into our Evolution backend.
Discussed with Patrick and the problem is the underlying Evolution Backend do
not support 'vcalendar 1.0' type.
However I think at least it can accept 'vcalendar 1.0' items and correctly
interpret and store it as 'icalendar 2.0', isn't it? Or this is something
handled by our Evolution backend?
If it really accepts 'vcalendar 1.0' input, not letting synthesis feeding it
'vcalendar 1.0' types perhaps is for efficiency considerations? i.e. The
transforamtion 'Synthesis internal' -> 'icalendar 1.0' -> 'vcalendar 2.0' is a
bit too long and productless.
But it indeed has some textual differences with the other approach :
'Synthesis internal' -> 'icaledar 2.0'.
At least for testing purposes, I would suggest the long transorming approach, it
makes synccompare a bit easier.
--
Regards,
Chen Congwu
Moblin China Development
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
--- End Message ---
--- Begin Message ---
On Tue, 2009-12-08 at 09:57 +0000, Chen Congwu wrote:
> However I think at least it can accept 'vcalendar 1.0' items and correctly
> interpret and store it as 'icalendar 2.0', isn't it? Or this is something
> handled by our Evolution backend?
client-test uses SyncSourceSerialize to access data in the backends
directly, without going through the Synthesis engine. This is
intentional, to avoid potential bugs in the Synthesis engine or
configuration.
The Evolution backend really can't import vCalendar 1.0. libical will
fail to parse it, because encoding rules are different. There might be
specific examples that happen to work, but this is not something that we
should count on.
> At least for testing purposes, I would suggest the long transorming approach,
> it
> makes synccompare a bit easier.
If you need it in a special case, then feel free to add something. But
please don't change the current testing.
--
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.
--- End Message ---
_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution
