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

[Milan Crha <mcrha redhat com>]

        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.

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.

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

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'd appreciate any opinion on the subject.

Will, if you want to clarify anything from what I said, please do.

I think we'll change the GSoC definition a bit, the task will be to
create GObject-based API for libical library, and the followup work will
be an integration into evolution of this new API. The followup means not
for the GSoC. Let's talk about this off-list.

        Bye,
        Milan