pnoltes commented on PR #441: URL: https://github.com/apache/celix/pull/441#issuecomment-1255122037
> > think the challenge is more in how to decide if a bundle does not need to be extracted, because it is already in the cache. > > .zip is just like .deb package: once installed into our global cache, the zip file is of no use and can be safely removed from the system. Each framework instance has its own private bundle cache, which does nothing but does bookkeeping like which bundle installed for this framework instance. When `celix_bundleContext_installBundle` is invoked, it just install in the private cache a reference to the real bundle directory in the global cache. Before a bundle can be installed into a framework instance's private cache, it must be first installed into the global cache via a separate tool like `dkpg` or a new Celix API `celix_system_installBundle`. > > Maybe we should call this global cache the System Bundle Store instead. Each working bundle exists uniquely in this store in unzipped format. Ah ok, now I understand the dkpg idea. Although technically good, I do then worry if we also need some support some repository system, which can be used to download/intstall bundle zips. Because in the current setup bundles are installed as zip, and if they also need to be installed in the "System Bundle Store" - per users - this default means some disk space overhead. Maybe it then also an idea to let the `install_celix_bundle` cmake command installed unzipped bundle in a already "System Bundle Store" complaint directory structure and allow a - per user and system wide - celix config file configure 0 or more "System Bundle Store" locations. IMO this should be feasible, especially because the bundle store should be read only. -- 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
