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 Fri, 02 Jan 2015 10:17:08 GMT
On 2 January 2015 at 00:32, Dennis E. Hamilton <>

>  -- replying below to --
> From: jan i []
> Sent: Thursday, January 1, 2015 13:23
> To:; Dennis Hamilton
> Subject: Re: Defining the 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
> (converters).
> 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.
> <orcmid>
>   OK, so exactly what is platform and what is core?
>   Is this specifically about the core/ and platform/ directories of the
>   repository.  Does it include the api/ folder as well?

>   I notice that platform/ has 3rdparty/ and also one src/ file each for
>   Apple, Linux, Unix, Win32, and Wrapper.  So these get picked out
>   depending on what one is compiling for?

Yes platform deals with differences in our the different platforms, that is
the only place for such things, the rest of the code is platform

Core is as explained, the central data structure and functions to
manipulate it. Core sits logically below filters (filtes use core)

API on the other hand is the "external face" of DocFormats and sits
logically on top of filters and core so API is NOT included in core.

> <orcmid>
> 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.
> <orcmid>
>   You lost me about seeing structure in "visual studio."
I had a feeling about that, please have a look at:

this is how CMake delivers the solution using
cmake -G "Visual Studio 12" ..
in a build directory

You see we have 2 main entities, consumers (the applications) and DocFormat
(the library).
In DocFormat you see the entities of the library.

jan i.

> </orcmid>
> rgds
> jan i.

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