[
https://issues.apache.org/jira/browse/STANBOL-431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13169574#comment-13169574
]
Rupert Westenthaler commented on STANBOL-431:
---------------------------------------------
I would use an ID that is configured as <engineID>. Even for "simple" engines I
would not use the Class name, but a reasonable default (e.g. the folder name
under /engines). This would create nice URLs and in my opinion we need to deal
with ID conflicts in any way - remember that even the class name is not
sufficient in OSGI where different versions of the same engine can run.
I think nice URLs are key if we want users to directly send requests to single
engines.
Any idea how to deal with ID conflicts? Is there a well known pattern how to
deal with this?
I can only think of something like an EngineManager service that tracks all
engines. Such a manager component could even use the ConfigAdmin to change the
ID of an engine if there is a conflict. The Engine whit the lower
service.ranking (higher service.id if both have the same ranking) would than be
changed to a free id by adding some suffix.
As an alternative we could also just make the engine with the higher
service.ranking accessible via the RESTfull interface.
For chains I would suggest, that if two do share the same ID, than only the one
with the higher service.ranking will be accessible via the RESTful interface.
WDYT
> Improve Enhancer/ REST endpoint
> -------------------------------
>
> Key: STANBOL-431
> URL: https://issues.apache.org/jira/browse/STANBOL-431
> Project: Stanbol
> Issue Type: Improvement
> Components: Enhancer
> Reporter: Florent ANDRE
>
> From STANBOL-414, Reto :
> Rest
> /enhancer
> /enhancer/engine/<engineId>
> /enhancer/chains/<chainId>
> - 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
