corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <j...@apache.org>
Subject Re: [dfwebserver] Python binding
Date Tue, 17 Mar 2015 12:38:13 GMT
On 17 March 2015 at 12:52, Franz de Copenhague <
franzdecopenhague@outlook.com> wrote:

>
>
> ----------------------------------------
> > 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?
>
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
>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message