You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@corinthia.apache.org by "Dennis E. Hamilton" <de...@acm.org> on 2015/01/01 20:31:13 UTC
Defining the Stable Kernel
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.
Re: Defining the Stable Kernel
Posted by Peter Kelly <pm...@apache.org>.
On 2 Jan 2015, at 8:31 pm, Dennis E. Hamilton <de...@acm.org> wrote:
>
> -- replying below to --
> From: jan i [mailto:jani@apache.org]
> Sent: Friday, January 2, 2015 02:17
> To: dev@corinthia.incubator.apache.org; Dennis Hamilton
> Subject: Re: Defining the Stable Kernel
>
> I had a feeling about that, please have a look at:
> http://people.apache.org/~jani/vs.JPG
>
> 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.
>
> <orcmid>
> I see the tree diagram, although I have no idea
> What is in each project at those levels.
>
> Since I don't see that solution anywhere,
> I have to deal with facts not in evidence.
> I gather it means I have to run CMake in
> order to have the view from VS that is in your
> screen shot. Where will I find the .sln file
> Once that is done?
It generates the Corinthia.sln in the same directory you ran cmake from.
—
Dr Peter M. Kelly
pmkelly@apache.org
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)
RE: Defining the Stable Kernel
Posted by "Dennis E. Hamilton" <de...@acm.org>.
-- replying below to --
From: jan i [mailto:jani@apache.org]
Sent: Friday, January 2, 2015 02:17
To: dev@corinthia.incubator.apache.org; Dennis Hamilton
Subject: Re: Defining the Stable Kernel
On 2 January 2015 at 00:32, Dennis E. Hamilton <de...@acm.org>
wrote:
[ ... ]
> 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:
http://people.apache.org/~jani/vs.JPG
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.
<orcmid>
I see the tree diagram, although I have no idea
What is in each project at those levels.
Since I don't see that solution anywhere,
I have to deal with facts not in evidence.
I gather it means I have to run CMake in
order to have the view from VS that is in your
screen shot. Where will I find the .sln file
Once that is done?
</orcmid>
rgds
jan i.
> </orcmid>
>
> rgds
> jan i.
>
>
Re: Defining the Stable Kernel
Posted by jan i <ja...@apache.org>.
On 2 January 2015 at 00:32, Dennis E. Hamilton <de...@acm.org>
wrote:
>
>
> -- replying below to --
> From: jan i [mailto:jani@apache.org]
> Sent: Thursday, January 1, 2015 13:23
> To: dev@corinthia.incubator.apache.org; 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
independent.
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:
http://people.apache.org/~jani/vs.JPG
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.
rgds
jan i.
> </orcmid>
>
> rgds
> jan i.
>
>
RE: Defining the Stable Kernel
Posted by "Dennis E. Hamilton" <de...@acm.org>.
-- replying below to --
From: jan i [mailto:jani@apache.org]
Sent: Thursday, January 1, 2015 13:23
To: dev@corinthia.incubator.apache.org; 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?
<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."
</orcmid>
rgds
jan i.
Re: Defining the Stable Kernel
Posted by jan i <ja...@apache.org>.
On 1 January 2015 at 20:31, Dennis E. Hamilton <de...@acm.org>
wrote:
> 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
(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.
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.
rgds
jan i.