> On 17 Mar 2015, at 6:52 pm, Franz de Copenhague > <[email protected]> wrote: > > Jan, is there any C consumer for the JS functions that you point out above? > > 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.
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. [1] https://docs.python.org/3/library/xml.dom.html — Dr Peter M. Kelly [email protected] PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)
