Paul Fremantle wrote:
Nice to meet you and get the feedback.
Same!
Can you outline the use case for the multi-valued attributes? It would
be nice to understand what you are using it for.
Sure - keep in mind I'm really just hacking around here... Anyway. An
incubating apache project called Tika piqued my interest. Tika looks at
a lump of bytes and tries to identify the file format. To support the
parsing and identification of file formats, there is a mime type
registry inside of Tika, which exists as an XML serialization. My
thought is that Tika could consume a mime type registry from WSO2
Registry (distributing management of the mime type registry to the web
instead of limiting it to a XML file somewhere).
Here's a snippet of the Tika mime type registry XML; the data model is
pretty easy to deduce:
<mime-info>
[...]
<mime-type type="application/x-bzip-compressed-tar">
<glob pattern="*.tbz" />
<glob pattern="*.tbz2" />
</mime-type>
[...]
<mime-type type="application/msword">
<magic priority="50">
<match value="\x31\xbe\x00\x00" type="string" offset="0" />
<match value="PO^Q`" type="string" offset="0" />
<match value="\376\067\0\043" type="string" offset="0" />
<match value="\333\245-\0\0\0" type="string" offset="0" />
<match value="Microsoft Word 6.0 Document" type="string"
offset="2080" />
<match value="Microsoft Word document data" type="string"
offset="2112" />
</magic>
<glob pattern="*.doc" />
<alias type="application/vnd.ms-word" />
</mime-type>
[...]
</mime-info>
Basically I'm trying to map the Tiki mime type data model into WSO2
Registry Resources and properties.
So a simple mapping (the first one, for bzip compressed tar above) would
be a single Resource (using the parent path /mimetypes) representing the
"tar" mime-type, with a property named "type" set to the mime type.
Each glob would be referenced from the bzip tar Resource using
setDependedOn(?). Each glob Resource would have a property named
"pattern". Globs would use the parent path /globs.
One xml element to one Resource and one xml attribute to one property
breaks down however for the second example where there are multiple
<match> elements. I can't (or don't want to) reference <match> elements
since they are unique to the <mime-type>.
So the way I see it I have a couple of options:
I can create a Resource for each <match> element, or I could set
multiple "match" properties on the Resource representing the <magic>
element.
So partly I just wanted to play around with WSO2 Registry, while perhaps
doing something useful: add multi-value prop support to Registry and
give Tika another option for managing its mime type registry :-)
Thanks Paul, let me know if I'm off base here.
Best,
Elliot
Paul
Elliot Metsger wrote:
Hi Paul,
Paul Fremantle wrote:
We will fix the comments.
Great! Thanks a lot :-)
Once we do, please can you comment on the issue with the following
text, just so that we have your legal permission to use the patch.:
By submitting this file I agree to grant a license to WSO2 for this
work for inclusion in WSO2 works (as per the WSO2 Software
Contributor License Agreement (http://wso2.org/files/wso2-cla.pdf)
and the Apache License 2.0 (http://www.apache.org/licenses/LICENSE-2.0).
Absolutely, will do.
I'm just starting to play around with registry, and it looks pretty
neat. :-)
Best,
Elliot
Paul
Elliot Metsger wrote:
I just created REGISTRY-93, regarding support for multi-valued
attributes for a resource.
I can't comment on the issue :( so I just wanted to add that I plan
on fixing the failing tests that the patch causes. I'll submit a
cumulative patch soon.
Best,
Elliot
_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
_______________________________________________
Registry-dev mailing list
[email protected]
http://wso2.org/cgi-bin/mailman/listinfo/registry-dev
