Mailing-List: contact dev-help@corinthia.incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@corinthia.incubator.apache.org
MIME-Version: 1.0
In-Reply-To: <COL127-W4372D539716A5EBDA041D3B5030@phx.gbl>
References: 
 <0000014c09c48e9f-af345524-63e8-45eb-ae67-dbdbad02e662-000000@email.amazonses.com>
	<COL127-W460EDE123A1BEB932440EEB5190@phx.gbl>
	<CAK2iWdQGRKFCYLV1EHsAspxxCo5dPiCUwOqrDhpgPQbL4VA1TA@mail.gmail.com>
	<COL127-W35967A5031AF88ED6BDAA0B5190@phx.gbl>
	<CAK2iWdQ3zJOLmke344J4v=bxdfg-mhF+r1Kyn+dCLiFD7Bz12Q@mail.gmail.com>
	<COL401-EAS2035F380D6EB196583C327B5060@phx.gbl>
	<522DE1E3-9D52-4418-B9D4-5F9125D8719E@apache.org>
	<COL401-EAS2778B2B06FDC2459107B9E1B5040@phx.gbl>
	<CAK2iWdSNctg0emuHXb_=GGagaXfjN4rwrowqxwRD1Qb7OWFisA@mail.gmail.com>
	<COL127-W3513A58727BB9F3508AF02B5020@phx.gbl>
	<CAK2iWdSym_TfPnaj=wdHZ5egNngJUa9FY-JEBv1VUxF-PqC8ug@mail.gmail.com>
	<COL127-W4997CD10E4AC7DE0F4EF31B5030@phx.gbl>
	<CAK2iWdREW-ifyi9+dUSV=jqeRLPMniYZjJLX-KUq1Piz5addzw@mail.gmail.com>
	<COL127-W4372D539716A5EBDA041D3B5030@phx.gbl>
Date: Tue, 17 Mar 2015 13:38:13 +0100
Message-ID: 
 <CAK2iWdT7d_Jm6hshArr+WcrNfeFqWFoN+TjzCeN5UH7uzVOVXg@mail.gmail.com>
Subject: Re: [dfwebserver] Python binding
From: jan i <jani@apache.org>
To: "dev@corinthia.incubator.apache.org" <dev@corinthia.incubator.apache.org>
Content-Type: multipart/alternative; boundary=089e0158c0a480122505117b3d8b

--089e0158c0a480122505117b3d8b
Content-Type: text/plain; charset=UTF-8

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

--089e0158c0a480122505117b3d8b--