Repository: celix Updated Branches: refs/heads/develop e2ad48f87 -> 9b5bca43d
CELIX-402: Adds a draft for the roadmap Project: http://git-wip-us.apache.org/repos/asf/celix/repo Commit: http://git-wip-us.apache.org/repos/asf/celix/commit/9b5bca43 Tree: http://git-wip-us.apache.org/repos/asf/celix/tree/9b5bca43 Diff: http://git-wip-us.apache.org/repos/asf/celix/diff/9b5bca43 Branch: refs/heads/develop Commit: 9b5bca43dda5ad47137d45a92900541f79c1d9c8 Parents: e2ad48f Author: Pepijn Noltes <[email protected]> Authored: Mon May 8 21:38:47 2017 +0200 Committer: Pepijn Noltes <[email protected]> Committed: Mon May 8 21:38:47 2017 +0200 ---------------------------------------------------------------------- documents/roadmap/improvement_ideas.md | 55 --------------- documents/roadmap/roadmap.md | 106 ++++++++++++++++++++++++++++ 2 files changed, 106 insertions(+), 55 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/celix/blob/9b5bca43/documents/roadmap/improvement_ideas.md ---------------------------------------------------------------------- diff --git a/documents/roadmap/improvement_ideas.md b/documents/roadmap/improvement_ideas.md index ff71d11..1218106 100644 --- a/documents/roadmap/improvement_ideas.md +++ b/documents/roadmap/improvement_ideas.md @@ -1,22 +1,4 @@ # Improvement Ideas - - -# Extend Dependency Manager C/C++ -The dependency manager offers declarative API for working with services and is arguable more easier -to use than the official OSGi Api. Extend the DM so that in can be used for virtually any bundle -without directly using the bundle context, bundle, module, service ref, service registration, etc API. -This provided a much smaller API providing almost the same functionality. - -This means: -1. Add support for service factory -1. Add support for providing listener hooks. Note that this is already supported by registering - a `listener_hook_service` service, but maybe a more abstracted way. -1. Add support looking up and opening resources in the bundle. -1. Replace add,remove, etc callbacks which uses the service reference, with callbacks using properties -1. Test if the dm correctly works when adding / removing provided services and service dependencies after a component is started. -1. Add support for bundle listener without needing the bundle.h API -1. Add support for listing installed bundles without needing the bundle.h/bundle_context.h API -1. Only required dependencies should be in celix_utils. This means: properties, lists, celix errors. # Introduce dlmopen for library imports. Currently library are loaded LOCAL for bundles. This works alright, but makes it hard to add a concept @@ -31,23 +13,6 @@ libraries in a given namespace. For bundle this can be used to create a library and load exported libraries int importing bundle namespace. A clean solution, but this currently only works for glibc (linux). -# Refactor service registry to a single threaded design -Celix currently has some nested lock. It would be preferable to remove these, but this is difficult -because they are used to sync events which react on registering/unregistering services. Specially when -a unregister/register event leads to other services being registered/unregisterd. One way to deal with -this sync problem is to remove it by adding a single thread which handle al interaction between bundles -and the service registry. - -# Create dfi descriptor generator -Create a descriptor generator which can parse type and service headers. -This can be relatively easy achieved by (e.g.) using the libclang library. -Also extend the CMake add_bundle command and create a CMake bundle_add_descriptors command to be able -to add the descriptors to the bundle - -# Use dfi descriptor in service registrations/references -When available dfi descriptors can be used in Celix to validate if service are compatible and -in case of the provided service having more functions than the consumer needs, create a (cast to) -a compatible consumer version. # Fix the performance use case and add C++ support There was a locking example which also functioned as a performance test to measure the impact of @@ -60,32 +25,12 @@ See [locking example tree](https://github.com/apache/celix/tree/216032cae956379d Celix is growing and getting more sub project, this is fine but maybe the structure needs a cleanup to create a more clear root directory structure. -# Add Support for running Celix as a single executable -For different reasons it could be interesting to support running bundles from a single executable. -Primarily security, but also startup performance. - - -To start this can be achieved by creating static version of the celix provided bundles. These static -bundles should have unique symbols, e.g shell_bundleActivator_create instead of a -"normal" bundleActivator_create. The normal activator functions should then -only be used (using a define or separated source file) when building a shared library bundle. -A additional property (e.g. "cosgi.auto.static.start=shell, shell_tui") can be used to specify which -symbol prefixes to use. - -Note that if this is implemented it would also be a good moment to add a compile option / launcher option -to disable dynamic loading of libraries. This way shared library based bundles can be used during -development, but for production a static executable with no capability to add bundles runtime -could be used if preferable. - # Extend the test environment # Improve documentation # Create one or more "real life" applications based on Celix to show the potential of Celix -# Investigate if in the pubsub admin the serialization and communication can be decoupled. -Now an admin is responsible for serialization and communication. - # Add pub sub admins. The current implementation uses JSON over multicast UDP or over ZMQ. One or more could be added. i.e. serialization based on Apache-Avro, communication over TCP / Kafka / Shared Memory http://git-wip-us.apache.org/repos/asf/celix/blob/9b5bca43/documents/roadmap/roadmap.md ---------------------------------------------------------------------- diff --git a/documents/roadmap/roadmap.md b/documents/roadmap/roadmap.md new file mode 100644 index 0000000..2594800 --- /dev/null +++ b/documents/roadmap/roadmap.md @@ -0,0 +1,106 @@ +# Roadmap + +Note this roadmap is still a draft. + +# Apache Celix 2.0.1 + +Date: TBD (juli/aug 2017?) + +## Improve PubSub (CELIX-407) + +1. Finalize introduction serializer services +1. Ensure code coverage of ~ 70% + +## Finalize Runtime Creation (CELIX-408) + +1. Ensure that the runtime command are used for testing some distributed test (e.g. pubsub) + +## Add Support for running Celix as a single executable (TODO issue) +For different reasons it could be interesting to support running bundles from a single executable. +Primarily security, but also startup performance. + +To start this can be achieved by creating static version of the celix provided bundles. These static +bundles should have unique symbols, e.g shell_bundleActivator_create instead of a +"normal" bundleActivator_create. The normal activator functions should then +only be used (using a define or separated source file) when building a shared library bundle. +A additional property (e.g. "cosgi.auto.static.start=shell, shell_tui") can be used to specify which +symbol prefixes to use. + +Note that if this is implemented it would also be a good moment to add a compile option / launcher option +to disable dynamic loading of libraries. This way shared library based bundles can be used during +development, but for production a static executable with no capability to add bundles runtime +could be used if preferable. + +# Apache Celix 2.1.0 + +Date: TBD (Jan 2018) + +Note a short comming is that there is still no good support for export and import libraries between +bundles. For Linux dlmopen is a solution, but for a more broader UNIX support a more "creative" +solution is needed (e.g. Just in time replacing the SONAME and NEEDED values in the respective shared libraries) + +## Extend Dependency Manager C/C++ (CELIX-409) + +The dependency manager offers declarative API for working with services and is arguable more easier +to use than the official OSGi Api. Extend the DM so that in can be used for virtually any bundle +without directly using the bundle context, bundle, module, service ref, service registration, etc API. +This provided a much smaller API providing almost the same functionality. + +This means: +1. Add support for service factory +1. Add support for providing listener hooks. Note that this is already supported by registering + a `listener_hook_service` service, but maybe a more abstracted way. +1. Add support looking up and opening resources in the bundle. +1. Replace add,remove, etc callbacks which uses the service reference, with callbacks using properties +1. Test if the dm correctly works when adding / removing provided services and service dependencies after a component is started. +1. Getting framework properties (e.g. bundleContext_getProperty) +1. Support for getting basic info from bundle (version, symbolic name, manifest) + +## Add framework services (TODO issue) +Apache Celix is a framework for service oriented programming, this should also include for interacting with the +framework itself. Create framework services for: + +1. bundle management: installing, Starting, Stopping, deinstalling, listing, etc bundles. +1. service registry info: nr of service registered, nr of service listeners, etc. +1. framework listenerL start, stop, error events (whiteboard) +1. bundle listener: installed, start, stop, deinstalled events (whiteboard) + +## Support dependency manager from framework (TODO issue) +Because the dependency manager is actual the preferred way to write bundles, this should be support +like "normal" activators" directly from the framework without using a static library. + +## Refactor Celix provided bundles to use dependency manager and framework services (TODO issue) +Refactor Celix bundles (shell, shell_tuu, RSA, etc) to use the dependency manager instead of a "vanilla" +bundle activator. The dependency manager should be the preferred way to handle services. +Also instead of directly using the API from bundle_context, bundle, module, etc the framework services +should be used. + +## Create dfi descriptor generator (TODO issue) +Create a descriptor generator which can parse type and service headers. +This can be relatively easy achieved by (e.g.) using the libclang library. +Also extend the CMake add_bundle command and create a CMake bundle_add_descriptors command to be able +to add the descriptors to the bundle + +## Use dfi descriptor in service registrations/references (TODO issue) +When available dfi descriptors can be used in Celix to validate if service are compatible and +in case of the provided service having more functions than the consumer needs, create a (cast to) +a compatible consumer version. + +# Apache Celix 3.0.0 + +Date: TBD (aug 2018) + +## Remove support for "vanilla" bundle activators (TODO issue) +When all Celix provided bundles are using the dependency manager and framework services support for +the "vanilla" bundle activator can be dropped. Also a lot internals can be refactored because the public +API should have shrunk quite a bit; This should lead to smaller code base -> less complex, easier to maintain +and a smaller footprint. + + +## Refactor service registry to a single threaded design (TODO issue) +Celix currently has some nested lock. It would be preferable to remove these, but this is difficult +because they are used to sync events which react on registering/unregistering services. Specially when +a unregister/register event leads to other services being registered/unregisterd. One way to deal with +this sync problem is to remove it by adding a single thread which handle al interaction between bundles +and the service registry. +
