[NEW KEP] KEP #17: Kolab XML Format 3.0

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Fri Mar 9 18:42:44 CET 2012


On 2012-03-09 14:41, Florian v. Samson wrote:
> Hi Christian,
>

Hi Florian,

> Am Freitag, 9. März 2012, 11:37 schrieb Christian Mollekopf:
>> On 2012-03-08 19:28, Florian v. Samson wrote:
>>> Technically you sure can, practically each change to the
>>> Kolab-Format will leave most of its clients behind for a long time.
>>> Or is Kolabsys planning to take care of patching ~10 Kolab-Clients
>>> (see
>>> <http://www-old.kolab.org/about-kolab-clients.html>) each time the
>>> Format changes?
>>
>> With libkolabxml we make it very easy for every vendor to update his
>> implementation.
>
> For libkolabxml being useful for other clients (which would be very
> helpful), a couple of language-bindings are missing, e.g.:
>
> - C-bindings for evolution-kolab (rsp. Evolution-Data-Server (EDS))
> - JavaScript-bindings for synckolab
> - Java-bindings for Kolab-WS
> - Etc.
>

The bindings currently offered are certainly not the exhaustive list of 
bindings we seek to ever provide with libkolabxml.

The two language bindings generated are currently PHP (actively being 
consumed by Roundcube as we speak) and Python (actively being consumed 
by PyKolab as we speak).

I would love for the people that require other bindings to join us in 
development of said bindings (on top of the library development).

For JavaScript for example, the realm of JavaScript engines that could 
be used can make it particularly hard for us to understand right off the 
bat, what needs to happen in order to generate these bindings so that 
they function properly.

C bindings, I think, do not need to be provided as C code can link to 
C++ libraries.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08




More information about the format mailing list