On 17 March 2015 at 12:52, Franz de Copenhague < [email protected]> wrote:
> > > ---------------------------------------- > > 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? > No not currently the consumer "corinthia" (desktop editor) will use them all. > > 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. > We need them all, the frontend calls the backend which call the C API. Sadly enough docformat library does not yet have a formal C Api, but we call functions deep within. I am working on the desktop editor (right now stuck in some 64bit issues), and as I work through it, I will have the functions calling the corresponding docformats functions. I did not expect you to implement all these bindings, since they do not exist, but merely used it to explain why I feel you use wrong names for your current bindings. Let us first get that up and running you have, and hope that I in the meantime can provide a consumer that shows all the needed calls. rgds jan I. > > franz > > >
