[
https://issues.apache.org/jira/browse/STANBOL-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13172180#comment-13172180
]
Rupert Westenthaler edited comment on STANBOL-414 at 12/19/11 11:33 AM:
------------------------------------------------------------------------
An other suggestion: Add an additional method Map<String,String>
getMimeTypeParameter() to the Blob interface. This would allow to access
additional parameters parsed by HTTP Requests within the Media-Type header.
For the implementation of this Feature in the InMemoryContentItem and the
InMemoryBlob I suggest to use javax.ws.rs.core.MediaType. This class is part of
'javax.ws.rs:jsr311-api'.
was (Author: rwesten):
An other suggestion: We should use javax.ws.rs.core.MediaType instead of
String for representing MimeTypes.
Currently on a lot of places Engines manually cut off parameters (such as the
charset). The same is currently true for the InMemoryContentItem. Using
MediaType would allow correctly check if a MediaType is compatible and respect
parameters such as the Charset regardless if the used ContentItem
implementation does already convert encoding to UTF-8 or not.
The additional dependency to 'javax.ws.rs:jsr311-api:1.1.1' should be OK.
> Refactor EnhancementEngine to support contents with multiple related parts
> --------------------------------------------------------------------------
>
> Key: STANBOL-414
> URL: https://issues.apache.org/jira/browse/STANBOL-414
> Project: Stanbol
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
> Attachments:
> 0001-CLEREZZA-414-changed-ContentItem-interface-and-utili.patch
>
>
> Some notes from a discussion with Rupert and Olivier
> ContentItem
> - getBlob() returns a blob of type multipart/mime iff the ContentItem was
> created from a multipart/mime content
> - ci.getBlob() eq ci.getPart(0, Blob.class)
> - ci.getUri()+"_main" eq ci.getPartUri(0)
> Rest
> /enhancer
> /enhancer/engine/<engineId>
> /enhancer/chains/<chaiId>
> - query params:
> Optional inputWithMetadata -> expects multipart/mime with 2 sections of which
> the first is rdf
> Optional outputWithContentParts[=<section-ordinal>] -> the result is
> multipart (instead of rdf) containing rdf as the first section and the parts
> in the second section, if there is more than one part this second section is
> itself multipart, this argument might be repated to have different sections
> Optional omitMetada -> no metadate in the result, makes only sense with
> outputContentParts argument, the result will correspond to the second section
> of the malipart returned without this argument
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
