corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Prototype web app, and Editor API
Date Thu, 12 Mar 2015 11:17:06 GMT
On 12 March 2015 at 12:10, Peter Kelly <> wrote:

> > On 12 Mar 2015, at 12:42 pm, Franz de Copenhague <
>> wrote:
> >
> > I have created my first Python binding patch
> > Please, let me know how to procedure and any feedback is welcome.
> >
> > So far, there are only 2 functions in the Python API.
> >
> > import dfutil
> > Import dfconvert
> >
> > dfutil.normalize("other.html")
> > dfconvert.get("input.docx", "output.html”)
> Wow, that was fast! I’m pleased to see you were able to put this together
> so quickly.
> For the record, I’m a big fan of Python too, and am using a lot for
> server-side functionality in my day job. So I’m all in favour of using it
> for our server-side code. (although I do lean towards Python 3, due to its
> unicode support).
> I’d like to merge in your patch, but I believe I need to confirm if you
> have previously signed an Apache contributor license agreement (
> <
>>) (can someone who’s been around
> a bit longer than me confirm whether patches like this require an ICLA, or
> this only required for commit access?).
We do not need a signed ICLA before Franz is invited to become a committer.
You (peter) can accept the patch with your committer hat on, review it, and
put it in master.

Usually people contribute patches (and are called contributors in the ASF
language), when the committers get tired applying the patches (or because
they  see the work as valuable) the person is invited as committer, at that
point a ICLA must be signed.

> On the topic of API, as I think Jan has mentioned, we’re still somewhat
> undecided on exactly what the DocFormats API should look like, outside of
> the three basic conversion options (get, put, and create). For doing these
> conversions, I would actually suggest it would be useful (and safer) to
> launch dfconvert as an external process, so that in the event one is
> running a Python web server doing lots of conversions as people open/save
> documents, then in the event of the conversion process crashing, the web
> server will keep running and can simply report that there was an error
> during the conversion. That is, it wouldn’t bring down the whole python
> interpreter.
I see the 3 functions as the start of our API, so you are right now it
would be safer to launch dfconvert, but that would bring us nothing
short/medium term, whereas starting to integrate the function we need will
bring us a step further.

> However, I think it’s definitely desirable to have these functions
> accessible through a Python API as well, so that they can be used as part
> of a wide range of programs. And this is even more the case for other
> functions that do things like manipulate the document, using the HTML DOM
> and CSS APIs. There are all sorts of applications in this would be useful -
> such as a web application which accepts (or generates) forms to fill out
> that are in .docx format, and needs an easy way to get at the information
> in the forms. This is just one example.
> As you get to learn more about the library, I’d be interested to hear your
> thoughts on the API and what some of the scenarios you think it would be
> useful, outside of just conversion.
The same here.

jan i.

> —
> Dr Peter M. Kelly
> PGP key: <>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

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