---------------------------------------- > Date: Tue, 17 Mar 2015 12:15:34 +0100 > Subject: Re: [dfwebserver] Python binding > From: [email protected] > To: [email protected] > > On 17 March 2015 at 12:05, Franz de Copenhague < > [email protected]> 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
