[jira] [Comment Edited] (CAMEL-21008) Improve discoverability of DJL for the various engines

["Aurélien Pupier (Jira)" <ji...@apache.org>]

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

Aurélien Pupier edited comment on CAMEL-21008 at 7/26/24 8:43 AM:
------------------------------------------------------------------

I proposed some ideas in the linked ticket which has similar structure and problem. here they are:
 * add protocol as category
 * 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
 * provide specific component for each protocol which are using djl 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.

I did not had time to dig more on that and do a proper pros/cons analysis

Note that I suspect that several other components are following the same structure and thus has the same kind of problematic.


was (Author: apupier):
I proposed some ideas in the [linked ticket|https://issues.apache.org/jira/browse/CAMEL-20871] which has similar structure and problem. here they are:


 * add protocol as category
 * 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
 * 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.

I did not had time to dig more on that and do a proper pros/cons analysis

Note that I suspect that several other components are following the same structure and thus has the same kind of problematic.

> Improve discoverability of DJL for the various engines
> ------------------------------------------------------
>
>                 Key: CAMEL-21008
>                 URL: https://issues.apache.org/jira/browse/CAMEL-21008
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-ai, camel-catalog
>            Reporter: Aurélien Pupier
>            Priority: Minor
>
> DJL component is supporting several engine [https://camel.apache.org/components/next/djl-component.html#_djl_engine_implementation] 
> An end-user might search for them instead of DJL when looking for the component.
> It would be nice to have a way to find DJL component when searching for pytorch, tensorflow or mxnet in the various tooling.
> this is a very similar issue with https://issues.apache.org/jira/browse/CAMEL-20871but for another component.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)