On 9/2/23 17:52, Pepijn Noltes wrote:
## 3.0.0 Preparation
Following the release of Apache Celix 2.4.0, we are planning a major
update (3.0.0). This also means that post-2.4.0 release, breaking
changes will be introduced, including the removal of certain
libraries, headers, functions, and bundles. For a more complete
overview of the anticipated breaking changes, see issue #509 [2].
The primary focus of these changes will be:
- Removal (or non-export) of the old C API that doesn't utilize a
`celix_` prefix.
- Removal of unused/unmaintained bundles. This includes the pubsub bundles.
So, why are these breaking changes being introduced?
Trimming the API is intended to streamline the public API of Apache
Celix, making the framework more manageable, especially by a smaller
team.
This will also help us get rid of lots of unused code, which will reduce
binary footprint.
It also provides great opportunity to improve the current API design.
For example, `celix_bundleContext_useServiceWithOptions` turns out to be
problematic:
1. It leads to deadlocks, especially various ABBA deadlocks. The most
recent deadlock is #629 [1].
2. It encourages misuse of the Celix event loop when used without
CELIX_SERVICE_USE_DIRECT.
3. Even with CELIX_SERVICE_USE_DIRECT set, it costs too much to use a
service in its current implementation.
The service layer should be made as (memory/CPU) efficient as possible,
since in a large application, there will be hundreds/thousands of
services/trackers.
We shall investigate any further optimization opportunity.
Regarding the removal of certain libraries/bundles and, in particular,
the pubsub bundles: My perspective is that the Apache Celix project
should concentrate on providing a native OSGi framework. This
framework should come with associated bundles that align with (and
adapt as needed) the OSGi specification, while also offering advanced
features, such as the Event Admin with support for remote events.
While the PubSub bundles offer valuable functionality, IMO they should
not be part of Apache Celix. Users can still access the PubSub bundles
from previous Apache Celix versions.
Note that currently PubSub has the least test coverage (67%) among all
bundles/libraries.
For a foundational framework like Celix, 95% coverage is very desirable.
Unless someone volunteers to actively maintain it and keep improving its
test coverage, I agree with its removal.
Considering the efforts the community has put into PubSub in the past
(#PR 389 [2] is still pending), we'd better hear other PubSub
contributors' opinions.
Besides removing unmaintained components, we still lack some bundles
useful for general application development like ConfigAdmin.
I have implemented something very similar to ConfigAdmin plus MetaType
using JSON/JSON Schema, and used it in my day job.
OSGi used properties for ConfigAdmin, and our current celix_properties
has no support for hierarchical structure, which is used a lot in
software configuration.
Given that hierarchical structure is well supported in various formats
(like toml used by Rust), I believe we should support it in our
ConfigAdmin implementation.
In closing, I believe a potential future goal for Apache Celix could
be to provide a native dynamic service framework promoting polyglot
solutions within a singular native process, based on a C API and
implementation. This could lean towards a low-level polyglot approach,
emphasizing FFI usage to create framework API bindings and
facilitating C-styled services to bridge various languages without
requiring a VM.
Beside SOA in a single process, I would like to have better support for
distributed computation:
* Service discovery support both RSA and RemoteEventAdmin is very
desirable.
* A powerful enough web server:
o Support reverse proxy to smooth legacy code migration [3]
o Request pipeline filter so that we can easily add various
pre/post request processing and security mechanism transparently
[4].
* Various Web based components should run under a single web server
instance together with legacy code.
o Currently http_admin/RSA/PSA all have their own instance without
any security mechanism.
* RSA descriptors/any other IDL should be generated from service
header [5].
* Hign performance IPC in a single process with security mechanism
like binder/kdbus.
o rsa_shm lackes security mechanism.
Presently, Apache Celix supports C and C++, but integrating Rust and
Python could be beneficial. Although Python support might depend on a
VM (PVM), it could be a worthy inclusion given that many C/C++
developers are familiar with Python. I share these thoughts as "food
for thought" but also to highlight that simplifying the Apache Celix
framework and its bundles would make achieving these goals more
feasible.
1:https://github.com/apache/celix/milestone/4
2:https://github.com/apache/celix/issues/509
What are your thoughts?
Best regards,
Pepijn
1: https://github.com/apache/celix/issues/629
2: https://github.com/apache/celix/pull/389
3: https://github.com/civetweb/civetweb/issues/1131
4: https://www.embedthis.com/appweb/doc/ref/architecture.html
5: https://github.com/apache/celix/issues/590
--
Peng Zheng
