corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kelly <>
Subject Re: [dfwebserver] Python binding
Date Tue, 17 Mar 2015 14:36:54 GMT
> On 17 Mar 2015, at 6:52 pm, Franz de Copenhague <>
> Jan, is there any C consumer for the JS functions that you point out above?
> Peter,
> Jan mentions this link
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.

Unfortunately the way in which these functions can be called depends on the web browser engine/webview
API in use. For example the way that it is done in iOS/OSX using Apple’s suppled UIWebView/WebView
classes is different to how it will be done for Qt bindings. Calling these functions from
a C program (or C++ or Objective C) depends on the API exposed by the web browser engine,
which can differ between applications.

DocFormats is logically separate from the editing code, in that it can be used in and of itself
- in particular, it is useful to have on the server side for various conversion processes
a website might need, and also for supporting conversion to be used by web-based apps built
on the library (which I’ve got an early proof of concept of in the repo, but without the
server component). In the latter case, the editing would be on the client’s browser.

Regarding the API of DocFormats, as Jan mentioned, this really hasn’t been decided on properly
yet, aside from the three main conversion functions. The one other set of APIs, which could
arguably considered public (UX Write uses them, and the Qt app will need to as well) are those
for representing CSS stylesheets. So as a next step towards python bindings, I would suggest
looking at the CSSSheet, CSSStyle, and CSSProperties classes.

The next thing after that is the DOM API. I’m undecided as to how that would be best exposed
in Python. We could write bindings as-is, although Python already has the xml.dom module [1]
which, if my understanding is correct, permits multiple implementations. So it may be worth
creating bindings to conform to that, so that people can re-use existing DOM-manipulating
python code based on the xml.dom APIs in conjunction with DocFormats.


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