ace-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bram de Kruijff (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ACE-316) Layout the OBR filesystem differently.
Date Fri, 12 Apr 2013 15:02:17 GMT

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

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

[~pbakker] I agree, but it may be more work then we bargained for. The Repository Service
spec (R5 section 132) has been overhauled to align with generic requirements and capabilities
model. From a functional perspective a full move to R5 means that we  will be able to 1) interact
with other R5 repositories (which will probably become the standard), 2) consumers can now
query a repository based on requirements and 3) it would open up the possibility of versioning
any type resource wherease at present only bundles have that luxury. However, there is no
no management interface or HTTP binding, so we would still need to invent it.

[~marrs] The spec allows for arbitrary resources and defines usable namespaces such as osgi.identity
/ osgi.content that are very generic (artist impression below) an we could extend those within
the standard. The real question is how we get the information. We can have bindex extensions
or custom recognizers that handle resources by (mime)type and know how to extract it, but
that is always a finite set (which may be fine).  In addition we could allow clients to enrich/overrule
the automagically extracted requirements/capabilities.

>From what I see there is little or no work on this in Felix and I could not find any others.
I could take a swing at this but it would probably boil down to a full replacement of the
current OBR covering all think linked issues :)

{code}
    <capability namespace='osgi.identity'>
      <attribute name='osgi.identity' value='my.jpg'/>
      <attribute name='type' value='unknown'/>
      <attribute name='version' type='Version' value='1.0.0'/>
    </capability>
    <capability namespace='osgi.content'>
      <attribute name='osgi.content' value='3de9cc9e394497a8edae493eab6b1894eb52f5c758159fa7edced25ac0be41bf'/>
      <attribute name='url' value='images/my.jpg-1.0.jpg '/>
      <attribute name='size' type='Long' value='123155'/>
      <attribute name='mime' value='image/jpeg'/>
    </capability>
{code}

                
> 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

Mime
View raw message