[
https://issues.apache.org/jira/browse/CAMEL-20871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aurélien Pupier updated CAMEL-20871:
------------------------------------
Description:
Toolings are currently using the catalog to let user browse components. In the
IoT space, users are often coming with protocol names, such as OPC UA, CANOpen
and more. Currently when searching for these protocols, no component are
showing up. But the component PLC4X is supporting them.
Adding all of these protocols in the description of the component, which is
part of the catalog, is making the description too long.
Other ideas to improve discoverability:
* add protocol as category but feels like a field designed for it
* improve catalog by adding "search field"/"keywords" but maybe too much
redundant with category?
* have tooling searching in documentation pages too (even if I do not see well
how it can work easily)
* provide Kamelets for each of the supported protocols. it has the benefit
that we can also add the specific dependency. Not sure really convenient
because we would like all the fields most fo the time so might be not really
fitting well.
* provide specific component for each protocol which are using plc4x under the
hood also has the benefit that we can also add the specific dependency. Can be
the best if there are specific parameter for a specific protocol. Will require
to keep the generic one so that newly supported protocols can be used without
modifications. Might require more maintenance work than a specific search field.
Note: initial discussion [https://github.com/apache/camel/pull/14419]
was:
Toolings are currently using the catalog to let user browse components. In the
IoT space, users are often coming with protocol names, such as OPC UA, CANOpen
and more. Currently when searching for these protocols, no component are
showing up. But the component PLC4X is supporting them.
Adding all of these protocols in the description of the component, which is
part of the catalog, is making the description too long.
Other ideas to improve discoverability:
* add protocol as category but feels like a field designed for it
* improve catalog by adding "search field"/"keywords" but maybe too much
redundant with category?
* have tooling searching in documentation pages too (even if I do not see well
how it can work easily)
* provide Kamelets for each of the supported protocols. it has the benefit
that we can also add the specific dependency. Not sure really convenient
because we would like all the fields most fo the time so might be not really
fitting well.
* provide specific component for each protocol which are using plc4x under the
hood also has the benefit that we can also add the specific dependency. Can be
the best if there are specific parameter for a specific protocol. Will require
to keep the generic one so that newly supported protocols can be sued without
modifications.
Note: initial discussion [https://github.com/apache/camel/pull/14419]
> Improve discoverability of PLC4X for the various supported protocols
> --------------------------------------------------------------------
>
> Key: CAMEL-20871
> URL: https://issues.apache.org/jira/browse/CAMEL-20871
> Project: Camel
> Issue Type: Improvement
> Components: camel-catalog
> Reporter: Aurélien Pupier
> Priority: Minor
>
> Toolings are currently using the catalog to let user browse components. In
> the IoT space, users are often coming with protocol names, such as OPC UA,
> CANOpen and more. Currently when searching for these protocols, no component
> are showing up. But the component PLC4X is supporting them.
> Adding all of these protocols in the description of the component, which is
> part of the catalog, is making the description too long.
> Other ideas to improve discoverability:
> * add protocol as category but feels like a field designed for it
> * improve catalog by adding "search field"/"keywords" but maybe too much
> redundant with category?
> * have tooling searching in documentation pages too (even if I do not see
> well how it can work easily)
> * provide Kamelets for each of the supported protocols. it has the benefit
> that we can also add the specific dependency. Not sure really convenient
> because we would like all the fields most fo the time so might be not really
> fitting well.
> * provide specific component for each protocol which are using plc4x under
> the hood also has the benefit that we can also add the specific dependency.
> Can be the best if there are specific parameter for a specific protocol. Will
> require to keep the generic one so that newly supported protocols can be used
> without modifications. Might require more maintenance work than a specific
> search field.
> Note: initial discussion [https://github.com/apache/camel/pull/14419]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
