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

2017-09-01 Thread Khurshid Alam



On Fri, Sep 1, 2017 at 5:29 PM, Milan Crha  wrote:

You do not need to parse. See the attached script. Run it as:
   $ cache-to-ics.sh 
~/.cache/evolution/calendar//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.



Thanks for the script. It worked.



___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2017-09-01 Thread Milan Crha
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/
> 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//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

cache-to-ics.sh
Description: application/shellscript
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


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

2017-09-01 Thread Khurshid Alam

Hi,

When I tried evolution 3.25.91, I noticed it doesn't dump online 
calendars as ical in  ~/.cache/evolution/calendar/ 
anymore. Instead it creates a database called "cache.db" in it?

What kind of database is it?

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?


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


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


Thanks.




___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers