corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Franz de Copenhague <franzdecopenha...@outlook.com>
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: jani@apache.org
> To: dev@corinthia.incubator.apache.org
>
> On 17 March 2015 at 12:05, Franz de Copenhague <
> franzdecopenhague@outlook.com> 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?

Peter,

Jan mentions this link https://cwiki.apache.org/confluence/display/Corinthia/API+reference
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.

franz


 		 	   		  
Mime
View raw message