Re: [Native-OSGi] Progress update

[Sascha Zelzer <s....@dkfz-heidelberg.de>]

Hi,

I just wanted to confirm that I think moving forward with the Celix 
project and extending it to support C++ is an important step.

To get started, we should probably discuss the directory layout of the 
Celix code repository. With respect to a (hypothetical) C/C++ OSGi spec, 
we could first try make the distinction between interfaces and 
implementation apparent at the directory level.  A first (incomplete) 
shot of mine trying to cope with these new requirements looks like this:

cmake
  ...
framework/  <-- current Celix C implementation
framework++/  <-- new Celix C++ stuff
   |---- wrapped/  <-- C++ implementation using the existing C impl.
   L---- native/   <-- independent C++ implementation (for experimentation)
  ...
osgi/
  |---- framework/
  |      |---- include/
  |      |      L---- osgi/
  |      |             |---- BundleContext.hxx   <-- C++ interface
  |      |             L---- bundle_context.h  <-- C interface
  |      L---- src/
  |---- cm/
  |      |---- include/
  |      |      L---- osgi/
  .      |             L---- cm/
  .      |                    |---- ConfigurationAdmin.hxx
  .      |                    L---- configuration_admin.h
  -      L---- src/


I tried to just add stuff on top of the existing repository to keep the 
impact low. With the second-level dirs, we could also add more 
sub-directories by e.g. having "c" and "cpp" folders below 
osgi/framework/ , but I thought trying to keep the hierarchy from 
getting too deep is better. We would still have to figure out how C and 
C++ implementations of service specifications could be marked as such 
and distinguished from each other (as long as these implementations are 
not contained in their own repository).

I would be more than happy to contribute the work done in the Native 
OSGi directory so far (especially the C++ interfaces [1]).

Looking forward to the discussions!


Thanks,

Sascha


[1] 
https://github.com/abroekhuis/NativeOSGi/tree/master/src/api/cpp/include/osgi

On 05/22/2013 09:17 AM, Alexander Broekhuis wrote:
> Hi all,
>
> Quite some time ago there was already something mentioned about Native-OSGi
> [1]. To recap: Native-OSGi is an effort to create a common specification
> for OSGi in C and C++. This effort was started by the CTK Plugin Framework,
> nOSGi and Apache Celix and although it has been rather quiet, there has
> been a lot of progress.
>
> This progress is not as much on the technical front, but more on the
> procedural front. During our initial talks we were asked if it would be
> worthwhile to write the Native-OSGi specification as an OSGi Alliance RFC.
> For us this meant a big boost in confidence wrt the specification. So of
> course we said yes to this!
>
> So in the past period we have been working on a RFP which is the first step
> towards writing the RFC for Native-OSGi. And now about a week ago this RFP
> has been published for the general public to read, discuss and comment on
> [2].
>
> For this work we would like to use Celix (and the Celix project) as home
> for, and as, the reference implementation. While Celix is writtin in C,
> Native-OSGi also specifies a C++ implementation, as such we do like to
> extend Celix to also support C++, but also like to start some discussion
> wrt a implementation in C++.
>
> So I would like to invite everyone to read and comment to the RFP on [2],
> but also would like to hear your comments regarding Celix and Native-OSGi
> and as Reference implementation as a reply to this mail.
>
> Thanks!
>
> [1]: http://incubator.markmail.org/thread/7rqtyp2so2duapfy
> [2]: https://www.osgi.org/bugzilla/show_bug.cgi?id=165
>

Re: [Native-OSGi] Progress update

[Alexander Broekhuis <a....@gmail.com>]

Hi,

2013/6/12 Sascha Zelzer <s....@dkfz-heidelberg.de>

> Hi,
>
> I just wanted to confirm that I think moving forward with the Celix
> project and extending it to support C++ is an important step.
>

Great to hear this!


>
> To get started, we should probably discuss the directory layout of the
> Celix code repository. With respect to a (hypothetical) C/C++ OSGi spec, we
> could first try make the distinction between interfaces and implementation
> apparent at the directory level.  A first (incomplete) shot of mine trying
> to cope with these new requirements looks like this:
>

I'd like to take some smaller steps in this, and start with a "new"
directory for the Native-OSGi compliant implementation. Some reasons are:
* Celix relies on APR all over the place, also on the API level. This was
an explicit choice when we made it. Moving to Native-OSGi breaks the
current Celix API.
* We have a (small) userbase using Celix, I would like to keep the current
codebase supported for them, see above point.
* Creating a new subproject gives us the opportunity to work on it and
breaking stuff, without to much impact on the current Celix source.


>
> cmake
>  ...
> framework/  <-- current Celix C implementation
> framework++/  <-- new Celix C++ stuff
>   |---- wrapped/  <-- C++ implementation using the existing C impl.
>   L---- native/   <-- independent C++ implementation (for experimentation)
>  ...
> osgi/
>  |---- framework/
>  |      |---- include/
>  |      |      L---- osgi/
>  |      |             |---- BundleContext.hxx   <-- C++ interface
>  |      |             L---- bundle_context.h  <-- C interface
>  |      L---- src/
>  |---- cm/
>  |      |---- include/
>  |      |      L---- osgi/
>  .      |             L---- cm/
>  .      |                    |---- ConfigurationAdmin.hxx
>  .      |                    L---- configuration_admin.h
>  -      L---- src/
>

This layout looks good, but I'd like to see is to make "framework" the new
Celix C implementation which is Native-OSGi compliant.


>
>
> I tried to just add stuff on top of the existing repository to keep the
> impact low. With the second-level dirs, we could also add more
> sub-directories by e.g. having "c" and "cpp" folders below osgi/framework/
> , but I thought trying to keep the hierarchy from getting too deep is
> better. We would still have to figure out how C and C++ implementations of
> service specifications could be marked as such and distinguished from each
> other (as long as these implementations are not contained in their own
> repository).
>

I'd like to follow the Celix directory layout a bit more and also use the
public and private directories. This gives a good sense as to what should
be exported and what not (wrt osgi metadata, but also wrt including and
building). Also, I do think have a c and cpp folder makes sense. That way
it is immediately clear in what language(s) a module is implemented.

Also, in your example you have eg "osgi/cm/include/osgi/cm", is the second
"osgi/cm" needed? For C it is an unneeded duplication, and it doesn't add
any extra information. It is already placed in the "osgi/cm" directory, so
why use it again?
Has it to do with C++ namespaces? If so, I'd like to split the h and hxx
files into own directories, this keeps the namespace specific for C++ and
doesn't make C use paths to include files.

I prefer the language directory on a higher level, if a certain module
doesn't have a c (or cpp) implementation or doesn't have any private files,
the directory isn't needed. Adding it later on doesn't have an impact on
the already existing directories etc.

cm/
    c/
        private/
            include/
            src
        public/
            include/
                configuration_admin.h
            src
    cpp/
        private/
            include/
            src
        public/
            include/
                osgi/cm/ConfigurationAdmin.hxx
            src


>
> I would be more than happy to contribute the work done in the Native OSGi
> directory so far (especially the C++ interfaces [1]).
>

If the others agree, I'd like to use that contribution as a means to make
you committer ;). So yeah, I'd like to that code moved to Celix.

-- 
Met vriendelijke groet,

Alexander Broekhuis