Comment author: Steffen Kachele <[email protected]>

Created attachment 54
RFP 156

This bug is used for discussion and collaboration on RFP 156 - Native OSGi.
The RFP can be found as an attachment.

Attached file: rfp-0156-NativeOSGi.pdf (application/pdf, 228494 bytes)
Description: RFP 156

from design.

Comment author: Sascha Zelzer <[email protected]>

Hi,

I would like to make some modifications to the current RFP document, including some restructuring of the headings and adding / refining contents. For some sections I already added some text snippets below but mostly I am recording my ideas in this comment. I am looking forward to comments on the suggested changes and would start adding the text passages if there are no upcoming objections.

Text in square brackets are comments not intended for inclusion into the RFP.

1 Introduction

[Slight change of wording:]

Even though the scope of the RFP is limited to C and C++, there are many other languages and compilers that create native binaries. While the focus will be on C and C++, the requirements should try to be open enough for these other languages. In other words, requirements not directly related to C and C++ should not force solutions which would block other languages that use the same runtime.

1.3 Technical Background

[We should emphasize that the existing frameworks are still incomplete and have slightly different foci. Also explain what the list is supposed to show:]

The participating projects already provide partial implementations of the concepts described in the OSGi Core specifications. Each implementation has different strengths and may differ from the others in the choice of solutions and techniques for implementing certain Core features. Within Native-OSGi the experience gained while developing these solutions and techniques will be used to create a common OSGi Core specification for the C and C++ languages.

In the following, distinct features of each OSGi-like implementation existing today and being part of the Native-OSGi efforts are listed:

• Apache Celix uses a ZIP-based bundle format and provides a C API covering large parts of the Core specifications.
• nOSGi provides a module layer implementation with a wiring model for dynamic updates of versioned shared libraries, based on runtime ELF header patching.
• CTK Plugin Framework provides an almost complete C++ API for the module, life-cycle, and service layer including support for bundle resources.
• CppMicroServices provides a C++ service layer implementation with a focus on type-safety

Combining these efforts and taking advantage of the already acquired expertise is assumed to be highly beneficial for the development of a Native-OSGi specification.

1.4 Module Layer

[I would suggest to move this section to the "Problem Description" chapter and probably split its contents to fit the sub-sections listed below. Further, we need to revise the text about linker dependencies since I think it is not correct. I will write a separate comment for that together with the sub-section contents for the "Problem Description" chapter]

2 Application Domain

[The introductory text contains some use cases, which should probably be moved to the "Use Cases" chapter and be expanded. I would also like to emphasize the importance of interoperability between C, C++, and Java services (possibly via remote services). The alternatives could be moved to the "1 Introduction" section. In this chapter, we could add some text about supported platforms:]

The Native OSGi specifications are assumed to be mostly written in a platform-neutral way. They should refer to the supported C and C++ language standard, with the exception of specifying the resolving process. The resolving process will likely need to take platform-specific and/or object file format features into account.

2.1 Advantages

[List some advantages of having a Native OSGi specification]

Compared to the traditional way of writing shared libraries, a Native OSGi system has the following advantages:

• Service - oriented modularity concepts for native developers, benefiting from years of experience gathered within the Java OSGi community
• Dynamic updates and reconfigurability of native code in a standardized way
• Alternative to JNI for Java and native code interoperability

2.2 Disadvantages

[List the (perceived) disadvantages]

• C/C++ lacks development tools when compared to Java, which could make the usage of OSGi concepts difficult for the average programmer
• The lack of language features like reflection will limit the scope of a Native OSGi specification

2.3 (currently 2.1) Terminology

[We should add some definitions here:]

• Shared library: This document consistently uses the term "shared library" for code loadable at runtime. For example on Windows, they are called Dynamic Link Libraries (DLL), on UNIX systems Dynamic Shared Objects (DSO), and on Mac OS platforms Dynamic Libraries (DyLib)
• Loader: A platform-specific program responsible for loaded shared libraries into memory and resolving their dependencies.

[What else?]

3 Problem Description

[I would like to actually merge the two sections 3.1 and 3.2 with the "1 Introduction" section, where it would fit better IMO. We could then list a couple of problems which need to be solved for a native OSGi specification:]

3.1 Native platform support

Due to the resolving and wiring process, we probably need to specify certain sets of "execution environments" on which an implementation must be able to run in order to be called compliant.

C and C++ standard

We should mention the C and C++ standards we are going to use. I would opt for C89 and C++98.

Shared library versioning

Talk about existing versioning schemes for shared libraries of the major platforms (Linux, Windows, MacOS) and how it relates to updating bundles/shared libraries.

Describe the nOSGi approach and show alternatives.

Mention Application Binary Interfaces (ABIs), their compatibility, and the relation to versioning schemes.

Exports and imports

How can exported "packages" (symbols) be handled in Native OSGi.

Memory management

Mention how Native OSGi handles memory management.

Binary and source bundle formats

Describe the problems/benefits of a ZIP-based native bundle format (shared library search path problems etc.).

How is ABI compatibility managed? (Meta-data describing the platform architecture, etc.?)

If the bundle format allows for "source bundles", how are the going to be build?

C and C++ compatibility

Describe the need for a way to call a C service via a C++ interface and vice versa.

Security layer

Describe the difficulties with specifying a security layer in Native OSGi. Maybe present a simplified solution.

4 Use Cases

[I would like to add another use case about distributed systems consisting of interacting C++ and Java OSGi services.]

5 Requirements

[After we added some or all of the above problem descriptions, we probably need to go through the requirements list again.]

6 Appendices

[We could add an "Appendices" chapter and talk about the following topics:]

6.1 Execution environments

[Suggest possible execution environments and]

6.2 Supported shared library formats

[We could give an overview about the commonly used object file formats and their features related to runtime dependency resolution.

• ELF
• Mach-O
• PE

from design.

Comment author: @bjhargrave

(In reply to Sascha Zelzer from comment BZ#1)

I would like to make some modifications to the current RFP document,

Sascha, Can you work with the other RFP authors to update the RFP for CPEG?

from design.

Comment author: Steffen Kachele <[email protected]>

Hi Sascha, thank you for restructuring. I'm fine with your changes and the new structure. In Section 1.3, I think we should focus a bit more on requirements. I think I can rewrite the subsection a little bit after you have integrated your changes.

from design.

Comment author: Sascha Zelzer <[email protected]>

Steffen, thanks for the feedback. I definitely agree that we should focus more on requirements.

(In reply to BJ Hargrave from comment BZ#2)

Sascha, Can you work with the other RFP authors to update the RFP for CPEG?

Yes, I will update the RFP during the next two weeks and Steffen and Alexander can review / modify it and add their comments.

from design.

Comment author: @bjhargrave

Comment on attachment 54
RFP 156

Latest RFP is now in github: https://github.com/osgi/design/raw/master/rfps/rfp-0156-NativeOSGi.pdf

from design.

Comment author: [email protected]

Did you already updated it Sascha? http://mrcoupon.com.tw/

from design.