-
Notifications
You must be signed in to change notification settings - Fork 91
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Prepare Celix 3.0.0 release #509
Comments
It reminds me of the brainstorm we had in #441 (comment) Now that #476 splits the cache and storage, the most straightforward way of supporting efficient sharing of bundles between multiple Celix instances is to add support for uncompressed bundle. This way, each framework instance has its own bundle cache like before, but for shared bundles, we extract them to someplace outside of bundle cache (maybe make them read-only), and then make symbolic links within the bundle cache to uncompressed shared bundles. For containered/sandboxed APPs, we can mount folder containing uncompressed bundles read-only into the container/sandbox, and include the mount point into the bundle path, so that the framework within the container/sandbox can find them. Our new
It's needed to perform binary footprint optimization for shared object. See #442
But OSGi does have Event Admin. The only problem I see with PSA is that it does not support zero-overhead in process communication like RSA: one socket per subscriber is too expensive for communication within the same process. PSA(Event Admin)/RSA represent two typical inter-component communication styles. We could add support for Event Admin, which both support zero overhead in-process and efficient inter-process communication, or we add support of zero-overhead in-process communication to PSA and rename it to Event Admin. Also it's worth noting that now service discovery for RSA/PSA(Event Admin) can be unified easily using dns-sd. |
As mentioned in #511, a crystal clear specification of the Celix component model or a reinterpretation of OSGi in the Celix context is very desirable. |
I agree with adding a Celix EventAdmin. The event admin is part of the OSGi spec and I also think a remote event admin makes sense and is easier to use for users. The main reason is that the current PubSub (and also the Remote Service Admin) needs extra manual work or codegen to be able to function. This manual work/codegen is needed to create DFI descriptors for serialization / remote invocation. I will add a separate issue for the event admin. |
Also: - Add some clarification of when error messaged are pushed to celix err in the celix properties header documentation.
For the next major version bump a lot deprecated functionality and functions can be dropped. Also some header files not meant for users should be made private.
An overview of the changes that should or can be done, before a Celix 3.0.0 release are:
Note that this does not mean that all deprecated functions/types usage (i.e. bundle_getState, etc) needs to be removed from Celix, but for a first 3.0.0 only that these functions / types are no longer useable downstream (so not useable for Apache Celix users)
The text was updated successfully, but these errors were encountered: