Re: [SyncEvolution] How to select the evolution target calendar
Hello Guy!
Lukas already replied to the 503 error. I'm afraid I don't have anything
to add to that. Hmm, or perhaps I do - see below.
On Thu, 2010-06-17 at 21:18 +0100, Guy Stalnaker wrote:
Where I want to go with my testing is a process that will allow users
of
MacOS Apple iCal a method to connect to and read/write their Oracle
Calendar data. Right now that is not possible. We've a project to
replace our Oracle Calendar but that's going to take two years. If I can
get our many Mac users a method to access their Oracle account using
Apple iCal, I'd be a very happy person. Because syncevolution writes
its data to a file using icalendar, there's a chance that same data file
may work with Apple iCal (as it works for Evolution) since Apple iCal
supports iCalendar (!?).
But how would you deploy this? It's true that you end up with all events
in a single iCalendar 2.0 file, but that's in the Linux home directory.
The connection from there to Apple iCal would still be missing.
It would be interesting to look into writing a CalDAV backend for
SyncEvolution. Given that, it should be possible to read/write the data
in a server that can be accessed by Apple iCal (which supports CalDAV).
But isn't CalDAV also supported by Oracle? Just wondering why iCal is
not already supported.
Also note that calendar synchronization with Oracle ran into issues with
iCalendar 2.0 data and the UID/RECURRENCE-ID properties. The main issue
is that Oracle expects the UID to be unique among all SyncML items. But
in iCalendar 2.0, multiple such items may (and must!) have the same UID
when they belong to the same meeting series. I never figured out how to
resolve this, so interoperability testing with Oracle got stuck.
My suggestion would be to get contact syncing working first, to avoid
these issues. Perhaps they caused sync failures and thus the 503 error
after all.
--
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.