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 _______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
