corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Defining the Stable Kernel
Date Thu, 01 Jan 2015 21:23:10 GMT
On 1 January 2015 at 20:31, Dennis E. Hamilton <>

> Our January 2015 report to the IPMC points out that we seek a stable
> kernel that is amenable to adding the work of more developers.
> I think it would be useful to circumscribe what qualifies as a stable
> kernel.  That is, how will we know when we have it?
> If we know what the end-state is, however modified by the experience of
> getting there, then there might be a short-term roadmap for it.
> At the moment I know I have no idea what we're driving toward for a stable
> kernel.

Let me tell how I see it:

If we start from the outside and dive into the project.

then the highest level is the consumers, they are applications that uses
the DocFormat library
below consumers we have the DocFormat library with a to be defined API ,
The library itself contains at top level of the different filters
Each filter convert to/from our internal format (which there has been
discussion in here to change).

In order for filters not to (mis)use internal functions, the core should
provide a API (to be defined).

core + platform is the "kernel" which offers services to the filters and
DocFormat API.

Right now our consumer, filters make calls deep within core, and use all
structures directly. As long as peter did all the coding, that was a very
efficient way of doing it, but as we get more people on board, we need
abstraction layers. A core API + structures, is such an abstraction.

Hope that clarifies things a bit, but bear in mind you can see the
structure in visual studio, but at lot of the abstraction has not been
discussed yet and far less  implemented.

jan i.

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