On So, 2011-01-02 at 20:30 +0000, Hans de Jonge wrote:
> Hi,
> 
> I want to synchronise a local agenda  of KDE's Korganizer-kontact with my 
> Nokia N900
> native calendar: using the file-backend.
[...]
> Besides VEVENT-s, the kontact calendar.ics file also contains VTODO
> and VJOURNAL items. These seem to be the problem: When I remove these
> with a plain text-editor, all 707 calendar-events are transferred
> properly to the N900 and subsequent synchronisation tests are
> succesfull enough.

You are accessing a single .ics file via the Evolution Data Server,
right? That only works for .ics files which contain one of VEVENT,
VTODO, or VJOURNAL, but not a mixture of them.

The SyncEvolution file backend as it exists at the moment also doesn't
help, because a) it expects each item to be a separate file and b) also
is limited to one kind of items per directory.

> A few things could be wrong:
> 1) for this calendar with multiple types I need to select another backend 
> than:
>    type=calendar:text/calendar or type=calendar:text/x-vcalendar
>    Obviously this backend should ignore VTODOs and VJOURNAL items when
>    requested.
> 
> 2) VTODO items are loaded by the backend, but since I am not yet interested 
>    in them (first things first: the calendar) I did not configure to send to
>    a proper place (in the N900, or some /dev/null for now) thereby also 
>    causing this lethal error.
> 
> 3) Something else.
> 
> Any Solutions?

Sorry, none at the moment.

It wouldn't be too hard to write a SyncEvolution backend which accesses
a single .ics file. If some developer is interested, then I can provide
further instructions. Might be useful by itself, independent of KDE.

There's also an on-going effort to enable an Akonadi backend, but it is
still work in progress. Dinesh (on CC) is driving that.

> Furthermor: it took me some carefull searching to find the specific N900 
> uri-feature:
>  uri=Calendar (the capital C), are these exact uri's documented somewhere or 
> can they
> be retreived from somewhere on the phone itself (e.g. a plain-text config
> file, or some Nokia technical document)?

I'm not aware of any documentation for that. For Nokia phones it always
happens to be the same, and SyncEvolution contains templates for phones
it knows about (see http://syncevolution.org/development/sync-phone):

$ syncevolution --template '?Nokia N900'
Available configuration templates:
   template name = template description    matching score in percent (100% = 
exact match)
   Nokia N900 = Template for all Nokia phones which support contacts, notes and 
combined tasks+events    100%
   Nokia N910 = Template for a fictious Nokia N910    80%
   Sony Ericsson K750i = Template for old Sony Ericsson phones, with separate 
databases for contacts/events/tasks/memos and SyncML 1.1    40%
   Sony Ericsson W595 = Template for all current Sony Ericsson phones, with 
separate databases for contacts/events/tasks/memos and SyncML 1.2    40%
   SyncEvolution Client = SyncEvolution server side template    40%


$ syncevolution --print-config -q --template "Nokia N900" | grep -v '#'
remoteIdentifier = PC Suite
PeerIsClient = 1
deviceId = foo
ConsumerReady = 1
defaultPeer = Nokia-N97-mini

[addressbook]
sync = two-way
type = addressbook
evolutionsource = SyncEvolution_Test_addressbook_1
uri = Contacts

[calendar]
sync = disabled
type = calendar
evolutionsource = SyncEvolution_Test_calendar_1
uri = event

[calendar+todo]
sync = two-way
type = virtual:text/x-calendar:1.0
evolutionsource = ical20,itodo20
uri = Calendar

[memo]
sync = two-way
type = memo
evolutionsource = SyncEvolution_Test_memo_1
uri = Notes

[todo]
sync = disabled
type = todo
evolutionsource = SyncEvolution_Test_todo_1
uri = task

Note that this template configures the "calendar+todo" source so that it
talks to the combined "Calendar" URI on the N900, whereas the local
storage is done in the separate "calendar" and "todo" sources.

-- 
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.


_______________________________________________
SyncEvolution mailing list
[email protected]
http://lists.syncevolution.org/listinfo/syncevolution

Reply via email to