On Jun 1, 2020, at 1:50 AM, Peter Palaga <ppal...@redhat.com> wrote:
Hi David, inline...
On 01/06/2020 06:55, David Jencks wrote:
I’ve been studying the camel-quarkus website wondering about generating the
table of extensions and I have some questions….
The page is named “list of extensions” but that’s not what it actually is. It
has tables of components, data formats, and languages, with links to the
extension they are in. I find this confusing.
You are right, it is confusing.
What are users likely to find most useful? Are they likely to think of the
components, data formats, and languages they need and want to know what
extensions are needed to run in camel-quarkus? Or are they going to search
directly for extensions? Or both?
I pondered on that too and here is the result:
* The structure on the Camel Quarkus side does not matter in most cases because
the extensions are mostly 1:1 to their respective Camel bits.
* The extension pages need to exist because they are required as a target for the
"extension guide" link from https://code.quarkus.io/ So the question is whether
we need both or extension pages only.
* Some extension pages contain Camel Quarkus specific config options, limitations and/or other
info that is relevant to all included Camel components, languages and data formats. It is
important that users see that Camel Quarkus specific info. Esp. googling for "camel
quarkus <camel-bit-name>" should bring a page listing that Camel Quarkus specific
info. I cannot see a way how to deliver that info (without too much repetition) within a
structure defined by Camel concepts.
* Based on the above, I think we should not impose the Camel structure on Camel
Quarkus. I think Camel structure should be kept in its original and natural
location, i.e. in the Camel Components reference area. At the same time, we
should try to enhance the components, language and data format pages there to
contain info on which platforms (SB, Karaf, WildFly, Quarkus) the given bit is
supported. Something like
| This [ component | language | data format ] is supported on
| * http://link.to/the-given-spring-boot-starter-page[Spring Boot]
| * http://link.to/the-given-karaf-bundle-page[Karaf]
| * http://link.to/the-given-camel-quarkus-extension-page[Quarkus]
| ...
| Please refer to the above links for the given platform's specific
| information.
If it’s the former, I think having separate index pages for the types of
“thing” would be a good idea, to match the main camel website. Then there’s
the question of what you get to when you select a “thing”. The extension pages
don’t seem to me to be a very good match for clicking on a “thing” in an
extension. I think it would make more sense to show a wrapper around most of
the main camel “thing” page, the wrapper indicating something about the
extension that provides the “thing”. Leaving out the information not useful
for camel-quarks would be a good idea too… I think this includes the “main”
camel maven coordinates.
I find this option cumbersome, thus -1 for me.
As part of this question, is Spring Boot relevant to camel-quarkus?
No
On the other hand, if users are more likely to be looking for extensions
directly, then actually having a table of extensions would be a good idea. The
list of extensions could also show up in the nav as a collapsible level 2 list.
Users rarely use navigation, they rather come via Google. What matters is
whether the page they were brought to contains the information they look for.
Furthermore, would it be good to have links from the main camel “thing” pages
to the quarkus extension providing them?
Definely +1
What do others think?
Thanks,
-- Peter
