Re: [Evolution-hackers] Recent modofication with eds cache (3.25.91)

[Milan Crha <mcrha redhat com>]

On Fri, 2017-09-01 at 11:45 +0500, Khurshid Alam wrote:
> When I tried evolution 3.25.91, I noticed it doesn't dump online
> calendars as ical in  ~/.cache/evolution/calendar/<addressbook-uid>
> anymore. Instead it creates a database called "cache.db" in it?
> What kind of database is it?

        Hi,
yes, it's an sqlite database.

> We, at Credence, so far, have been using a python client to sync
> other machines in lan which do not have internet.
> We simply pick "calendar.ics" from eds cache and sync it with other
> machine using syncevolution.
>
> This recent change will definitely break our script. Is there any way
> you would keep the old behaviour along with new one? 

No. That would mean double disk storage and/or other complications,
which doesn't worth it considering you are touching internal eds files.

> Although it is still possible to parse "cache.db" (assuming it's
> sqlite), but I do not want to resort to such crude method.

You do not need to parse. See the attached script. Run it as:
   $ cache-to-ics.sh ~/.cache/evolution/calendar/<calendar-UID>/cache.db
and it'll create calendar.ics in the current directory containing
the data from the cache. The resulting file can have issue with CRLF,
but libraries like libical can parse it anyway.

> But I would rather use proper backend, but it seems gobject-
> introspection bindings for ecal is also missing. I me an there is
> binding for ebook but not for ecal. Why is that?

It's due to libical, which can be compiled with some introspection
bits, but they are not good, especially for older versions of libical.
There is a plan to port libecal to use libical-glib instead, which will
make introspection for libecal possible and fairly easy.
The libical-glib is merged into libical upstream (it begun as a
separate project), thus when it's released and distributions pick it
and there will be time to dive to such a large change on the eds side
(and anything connecting to libecal and/or providing a calendar
backend), then the plan will move forward.
        Bye,
        Milan

Attachment: cache-to-ics.sh
Description: application/shellscript