corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Franz de Copenhague <>
Subject RE: [dfwebserver] Python binding
Date Tue, 17 Mar 2015 11:52:43 GMT

> Date: Tue, 17 Mar 2015 12:15:34 +0100
> Subject: Re: [dfwebserver] Python binding
> From:
> To:
> On 17 March 2015 at 12:05, Franz de Copenhague <
>> wrote:
>>> I think my technical comment might have got lost in translation :-)
>>> Could you please consider naming your bindings different, I actually
>>> thought you had copied the dfconvert code
>> I think that using a similar name to the C API which is been binding to
>> python makes sense and it is how other bindings are done. So, a developer
>> whom knows DocFormat C API would understand the python API at first place.
>>> I would suggest (but it is your choice) to put all bindings in 1 source
>>> file and name it e.g. docFormatPython.c
>> The bindind is following the consumers C API pattern with 2 main.c files
>> for dfconvert and dfutil that generates 2 executables dfconvert and dfutil.
>> For me, makes sense your suggestion if you have plans to refactory the
>> DocFormat C API and have only one main.c with dfconvert and dfutil features
>> all together.
> Please be aware dfconvert and dfutil are consumers the USE docFormat.lib
> they do not represent the docformats API.
> if you look inside dfconvert/dfutil they call functions inside docFormats
> (the library) that is part of the API.
> I think peter gave you a list of all the JS functions we have that calls
> back info the library (it is some 40+ calls)
> So seen from a release perspective our aim is to have
> docFormats library with a C-api
> dfconvert executable as a consumer of docFormats
> dftest executable as a consumer of docFormats
> dfWebServer executable as a consumer with python bindings fo docFormats
> So you can dfconvert, dftest and dfWebserver is parallel (dfutil is more or
> less on its way out).
> I hope that explains why I suggested a name change.
> rgds
> jan I.

Jan, is there any C consumer for the JS functions that you point out above?


Jan mentions this link
but I am seeing a lot of functions required by the front-end aka Editor Library. Would you
split up in 2 list for front-end and back-end? Also, will be very helpful to know what is
the corresponding C API for each back-end functionality.


View raw message