[ 
https://issues.apache.org/jira/browse/ACE-316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13630064#comment-13630064
 ] 

Bram de Kruijff commented on ACE-316:
-------------------------------------

A small analysis;

At present the client is 'in charge' of the filename as seen in 
BundleStore#put(String, InputStream) and BundleStore#remove(String). This is 
reflected in the rest API (implemented by BundleServlet) that supports POST 
/<filename> and DELETE /<filename>. This filename does not actually have any 
meaning in the OBR context, but it is there.

If we want to keep this interface and only address the fs scalability we could 
simply have to keep an internal mapping of filename to internal path or use a 
simple hashing strategy. However, this is not very elegant and, as Marcel 
suggest with <BSN>/<version>, we may want to use a more logical layout.

Therefore I suggest to break the API by removing the filename and use a file 
naming strategy based on the actual bundle metadata. In addition, as the OSGi 
specification states that a BSN should follow the reverse domain convention, I 
think it makes sense to create sub directories for each part of the BSN using a 
split-by-dot.

Thus, the API would be BundleStore#put(InputStream) and 
BundleStore#remove(String), reflected by the rest API supporting POST / 
(returning a 201 Created response with location) and DELETE /<actual location>. 
The location for org.apache.commons.lang-2.6.jar would then be 
store/org/apache/commons/lang/2.6/org.apache.commons.lang-2.6.jar
 
                
> Layout the OBR filesystem differently.
> --------------------------------------
>
>                 Key: ACE-316
>                 URL: https://issues.apache.org/jira/browse/ACE-316
>             Project: ACE
>          Issue Type: Question
>          Components: OBR
>            Reporter: Marcel Offermans
>            Assignee: Bram de Kruijff
>
> Currently, the OBR uses a single folder to store all artifacts. That does not 
> scale too well as OS specific directory limits might interfere. We should 
> implement a more hierarchical storage format, such as: <BSN>/<version> or 
> even one where each part of the BSN becomes a folder.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to