Re: [Evolution-hackers] Introspection enablement for libecal - huge changes needed?

[Patrick Ohly <patrick ohly gmx de>]

On Wed, 2014-05-14 at 15:34 +0200, Milan Crha wrote:
>       Hello,
> maybe you noticed that we have a GSoC project for this year, to enable
> introspection for calendar part of evolution-data-server (libecal),
> which will make it usable for other languages as well.

As said already, doing this as add-on of libical and then later taking
advantage of it in EDS seems like the right approach.

> Will is a student which will do the main work. The current problem is
> libical, its icalcomponent, enums and all other structures. I thought
> that we will be able to introspect this with simple boxed types, but it
> doesn't seem to be possible, thus the only option I can see is to
> massively change API of the calendar and define proxies for libical
> structures and enums. These proxies would be fully GObject-based, which
> might be a plus, I hope.
>
> I would, for example, define a GObject ICalComponent, which would have
> its i_cal_component_* API functions, mimic all the icalcomponent API,
> hiding the icalcomponent structure in the background.

Would it be possible to keep the current EDS API around and just add the
new introspectable API?

> Such change will be huge, but more importantly it'll be an earthquake
> for anything using libecal (the ECalComponent would not use
> icalcomponent anymore, it would start using ICalComponent instead).

ECalComponent would use a proxy of the original icalcomponent, right? If
the introspection layer in libical has a way to convert to and from the
original icalcomponent and the introspectable proxy, then ECalComponent
could convert back and forth as needed, depending on which API the EDS
client uses.

> Because of this earthquake, I would like to hear from others their
> opinion. Maybe we overlooked some option in introspection (there is
> preferred to create introspection based on code annotations, not to
> define them by hand), but I'm afraid the most of the projects like
> SyncEvolution, whether it'll be able to handle such change gracefully.

I've made my peace with ABI and API changes in EDS ;-} I'm not happy
about them, but I can handle them with a combination of ifdefs and
compilation of backend shared objects on different Linux distros. Just
give me enough and explicit warning beforehand.

If an API change can't be avoided, then don't let SyncEvolution hold you
back.

Bye, Patrick