[GitHub] [celix] pnoltes commented on pull request #441: [RFC] Skip bundle extraction when reloading bundle from cache.

[GitBox <gi...@apache.org>]

pnoltes commented on PR #441:
URL: https://github.com/apache/celix/pull/441#issuecomment-1236383556

   Interesting PR...
   
   On the background I was also looking to how bundle cache work in Celix and whether this should and can be improved.
   
   The Celix bundle cache exists because we wanted to work with zip files like Java (jar is a zip file, but where the MANIFEST file is always the first entry). With zip files you can store .so lib files and resources file in a single deployable unit. 
   
   If I read the OSGi correctly, Celix is currently not following the OSGi spec. The spec talks about bundle resources:
   https://docs.osgi.org/specification/osgi.core/8.0.0/framework.lifecycle.html#i3258563
   And it talks about persistence storage:
   https://docs.osgi.org/specification/osgi.core/8.0.0/framework.lifecycle.html#i1236436
   
   The current Celix bundle cache solution provides both. This has grown this way and the primary reason is that you need to extract the bundle zip files before you can use the resources (especially the so files, dlopen does not work in a zip file).
   If I could start over, I would have handled bundles as (read only) dirs instead of zip files.
   
   I think the way forward is the first split the cache and storage. If I am correct Celix only uses/needs the storage in the Celix::http_admin bundle (to setup soft links to other bundle resources, because otherwise civetweb cannot provide resources from multiple bundles).
   For example for the future the `celix_bundle_getEntry` still returns the bundle cache entry, but a new function (`celix_bundleContext_ getDataFile(const char*)` returns the bundle storage (if enabled).
   
   But I also think that we can refactor the bundle cache so that this is not managed per framework instance, but on a global celix cache dir. Maybe something like `~/.cache/celix/bundles` or `~/.celix/cache/bundles/<bundle-id>`. maybe the  ID can be a hash of the zip file. Note that this also needs some (file-based?) locking mechanisme and I do not have yet experience with this. This should really save disk space and improve startup times. 
   
   An other option would be to also support bundles as dir and let the `celix_bundle_getEntry` function directly return the bundle dir (ideally as read only).  
     
   WDYT?


-- 
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-unsubscribe@celix.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org