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.
>
> It is pretty strait forward to do in a command shell:
>
> dfconvert get input.docx abstract.html
>
> And do the same in python or javascript
>
> import dfconvert
> dfconvert.get( "input.docx", "abstract.html")
>
> var dfconvert = require("dfconvert");
> dfconvert.get("input.docx", "abstract.html")
>
> franz
>
>
