[Kolab-devel] libkolabxml C language bindings

[Christian Hilberg]

Hi Christian,

Am Donnerstag 12 April 2012, um 11:58:06 schrieb Christian Mollekopf:
> Hi Christian,
> 
> Yes, you can not directly link to the code like this, that is clear. But I 
> don't see the problem in having a wrapper in the evolution code (written in 
> C++), which fills your internal structs right away (which are evolution 
> specific).
> 
> The thing with the C api is that we would have to duplicate the whole 
> containers, withouth really gaining anything. You would still have to write 
> the mapping to your internal containers, we would just do an additional copy 
> first to the kolab-C-containers. Obviously you wouldn't have to touch a C++ 
> compiler this way, but I don't see how that can be the problem.

This approach clearly has the advantage of not duplicating anything, which
is a goal you take much effort to achieve - as far as I can tell from the
libkolabxml sources I've seen.
  However, GNOME is a C world, and we would most probably not succeed "selling"
the necessity of a C++ compiler to upstream Evolution or GNOME in order to compile
an Evolution plugin. evolution-kolab is, presently, packaged separately, but
there are upstream efforts to group all of the groupware plugins into a single
package, so pulling in C++ code directly into the plugin is not an option I see
fit for our project, whereas dependency on an external C++ lib with a C language
binding would be okay I think.
  Doing the data mapping straight, as you propose above, also means that no other
project than just evolution-kolab can benefit from our efforts. True, a C language
binding would mean doubling some code (there may not even be the necessity to
double the container classes as such, you can reference them from C as opaque objects,
only you need a full set of C accessor functions, which, in turn may return opaque
objects you need C accessors for, until you've reached the level of plain C
data types like strings, numbers, structs etc.), but it would provide means for
other C projects as well to benefit from libkolabxml.

> So therefore I don't think providing C-bindings is something we want to do, 
> you are of course free to contribute them if you still see value in them.
> 
> I searched for a project which would let us generate C-bindings for C++ code 
> (because generating would definitly be preferred), but the only thing I found 
> is a GSOC project on SWIG from 2008 I think. No idea if that works, but you 
> might want to take a look at that. 
> (http://codewrapper.com/wiki/index.php?title=SWIG_GSoC_2012_ideas_page#Idea_2:_Support_for_C_as_target_language)

I'll be having a look around, maybe there's something worthwhile to find
(though I have doubts how much a generator can do about STL and BOOST).

> Of course I am very much willing to work with you together, but can't offer to 
> write C bindings for you for the reasons lined out.

We'll be in touch! Thank you very much for your cooperation. This is
much appreciated.

Kind regards,

	Christian

-- 
kernel concepts GmbH       Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen
http://www.kernelconcepts.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/devel/attachments/20120412/3e5a4876/attachment.sig>