PengZheng commented on PR #441: URL: https://github.com/apache/celix/pull/441#issuecomment-1236657700
My gut feeling is that we shall establish a natural transformation between Celix's modeling and OSGi specs, which addresses intrinsic language differences (like java class loader) as smooth as possible. That being said, the system-wide global Celix cache you suggested seems to me the right way to go. And indeed, file locking is needed to share the cache between multiple Celix framework instances. If we want to build cache management into the Celix framework instead of delegating it to a separate command like `dpkg`, then we have to deal with the annoying interaction between POSIX advisory lock and multi-threading: https://github.com/sqlite/sqlite/blob/e04c9f4b33521a99388ce27eb46a0947fda44a26/src/os_unix.c#L1027 As for the structure of the cache , I guess we can steal some idea from conan's design? Something like `~/.celix/bundles/<bundle_name>/<bundle_version>/<hash>` will permit multiple versions of the same bundle live happily together. I suggest we keep per framework private cache to do some minimal bookkeeping like which version of which bundles is installed for the current framework instance. Of course, any unzipped bundle exists solely in the gloabal Celix bundle, and the private cache merely reference into it for real bundle resource. Maybe the private cache can also serve as private storage, which is both readable and writable, in the contrary to the read-only global cache? Before we refine Celix's modeling to make it align with OSGi specs, I cannot answer this question. With such a modeling in place, we can develop a very useful notion of general APP for embedded Linux. Such an APP can run in one of the two modes: - **Standalone Mode**, the bundles implementing the business logic and all their dependencies are contained in a Celix container, running in a separate Docker conainer, or any light weight homemade sandbox. - **Plugin Mode**, the app bundles and all their dependencies are running with other bundles in a monolithic process. Use standalone mode, we can constrain each app's resource usage, while the plugin mode will be valuable for highly resource constrained environments. The user can switch between two modes easily. Supporting multiple-version of the same bundle is essential for this usage, since APPs have very different release schedules and thus are likely to depend on different versions of the same bundle. The global cache guarantees that for any specific version of any specific bundle, there is only one unzipped bundle system-wide. That means though each app may carry all its dependencies, there will be no duplication system-wide. Now, I really should find a place to sit down, and have a good reading of the specs before any prototyping attempt. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@celix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
