> On Sep 22, 2015, at 3:15 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: > > I got a bunch of more components to use more labels. > > However for login credentials I used "security". But I wonder if we > should use "login" for username/password etc so they "stand out" as > security can have a bunch of other options for TLS/chipers/and > whatnot.
Would “Authentication” work better? For components that have other types authentication/login options (SSH for example) could group them all together. Dan > > > > On Mon, Sep 14, 2015 at 10:38 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: >> Hi >> >> Yeah maybe advanced is a term that is maybe used in other products. So >> I guess its after all an okay word. >> >> I logged a ticket about this >> https://issues.apache.org/jira/browse/CAMEL-9131 >> >> On Thu, Sep 10, 2015 at 4:00 PM, Daniel Kulp <dk...@apache.org> wrote: >>>> Using the word advanced is imho not always the best word for uncommon >>>> options. Maybe some good english word for "uncommon / seldom / rare" >>>> can be used. >>> >>> The main reason I suggested “Advanced” is that that is what Apple seems to >>> use in it’s gui for similar things. If you are on a Mac, go to your >>> Settings app and open up the “Security & Privacy” settings. There is an >>> “Advanced…” button. Likewise in the “Internet Accounts”. There were a >>> few other places I saw this as well while poking around the various OS X >>> applications preferences panels. >>> >>> Of course, this could be something Apple has localized to my US version of >>> OSX. No idea. :-) No idea what MS does in Windows. >>> >>> Dan >>> >>> >>> >>>> On Sep 10, 2015, at 2:30 AM, Claus Ibsen <claus.ib...@gmail.com> wrote: >>>> >>>> Hi >>>> >>>> Yeah it was the idea to add more labels to the options. The idea is >>>> that you can append more labels separated by comma, eg >>>> >>>> "consumer,common,security" >>>> "consumer,common" >>>> "consumer,networking" >>>> "consumer,security" >>>> >>>> And if a component is only consumer or producer then that would be >>>> implied, and you do not need to have "consumer" or "producer". >>>> >>>> Though as we know naming is hard in IT so sometimes it can be a bit >>>> hard to find a good name and categorize all those options. >>>> >>>> And there is also some inherited options like synchronized / >>>> exchangePattern that most people do not use, but what label should >>>> they have? >>>> >>>> Using the word advanced is imho not always the best word for uncommon >>>> options. Maybe some good english word for "uncommon / seldom / rare" >>>> can be used. >>>> >>>> If we get all that done eventually then all the components is >>>> documented out of the box and is also tooling friendly and using the >>>> same grouping of the options, as well documentation (its just the >>>> javadoc) eg all the stuff there is out of the box in the json file. >>>> >>>> >>>> >>>> On Thu, Sep 10, 2015 at 2:00 AM, Jon Anstey <jans...@gmail.com> wrote: >>>>> Yeah, I like the idea of an "advanced" label for non-common options. I've >>>>> often been overwhelmed myself at the list of options for some components >>>>> :-) I imagine it also clutters up UIs for the sake of showing options only >>>>> a small number of people may ever use. >>>>> >>>>> Cheers, >>>>> Jon >>>>> >>>>> On Wed, Sep 9, 2015 at 2:23 PM, Daniel Kulp <dk...@apache.org> wrote: >>>>> >>>>>> I’m working with the UI folks in Talend to enhance the tooling that we >>>>>> provide. Right now, we have various components with specific parameters >>>>>> exposed. This “kind of works”, but as new parameters are added in Camel >>>>>> we >>>>>> have to keep things up to date and such. We’re trying to switch to >>>>>> using >>>>>> the json stuff that is generated at build time (great stuff, BTW) so that >>>>>> all the parameters that are available is presented to the users. >>>>>> Currently, there are labels for “consumer” and “producer” and anything >>>>>> not >>>>>> labelled one of those is common between the two. That’s a great start. >>>>>> However, while testing with some users, we’ve run into a usability >>>>>> problem: some of the components have soooooo many parameters, many of >>>>>> which would rarely ever be used, that trying to find the useful stuff >>>>>> that >>>>>> they care about is harder than it should be. For example, take a look >>>>>> at >>>>>> the file component: >>>>>> >>>>>> http://camel.apache.org/file2.html >>>>>> >>>>>> There are 7 “common” options, but for the consumer, there are then an >>>>>> additional 51 options. It’s really too many to present in a single list >>>>>> and not have the user go “what?!?”. >>>>>> >>>>>> >>>>>> Would there be any objections to adding an “advanced” label to options >>>>>> that are generally not normally used by say 90% of the use cases? I >>>>>> know >>>>>> that determining whether something is “advanced” or not can start heading >>>>>> down the path of bike shedding and the whole “what’s advanced for one >>>>>> user >>>>>> isn’t for another” and all that, but I think we need to have something to >>>>>> help out with this. Another thought was an additional “advanced=true” >>>>>> or >>>>>> “userlevel=1” or similar attribute to denote this, but the label >>>>>> functionality is already there and it seems to be perfect for this. >>>>>> >>>>>> I did quick look to see how many options we have. I parsed/processed >>>>>> all >>>>>> the component json files (didn’t look at the models or data format) and >>>>>> there are over 10,000 options. It’s a huge task to go through each of >>>>>> them, but if we can agree on a path forward, we can start tackling some >>>>>> of >>>>>> the more used components and then see how that works. File, http, >>>>>> jetty, >>>>>> jms/sjms, etc… Longer term, this info could be used to provide more >>>>>> useful component pages for the docs, putting the more useful stuff at the >>>>>> top. >>>>>> >>>>>> >>>>>> Thoughts? Objections? Other ideas? >>>>>> >>>>>> -- >>>>>> Daniel Kulp >>>>>> dk...@apache.org - http://dankulp.com/blog >>>>>> Talend Community Coder - http://coders.talend.com >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Jon >>>>> --------------- >>>>> Red Hat, Inc. >>>>> Email: jans...@redhat.com >>>>> Web: http://redhat.com >>>>> Twitter: jon_anstey >>>>> Blog: http://janstey.blogspot.com >>>>> Author of Camel in Action: http://manning.com/ibsen >>>> >>>> >>>> >>>> -- >>>> Claus Ibsen >>>> ----------------- >>>> http://davsclaus.com @davsclaus >>>> Camel in Action 2nd edition: >>>> https://www.manning.com/books/camel-in-action-second-edition >>> >>> -- >>> Daniel Kulp >>> dk...@apache.org - http://dankulp.com/blog >>> Talend Community Coder - http://coders.talend.com >>> >> >> >> >> -- >> Claus Ibsen >> ----------------- >> http://davsclaus.com @davsclaus >> Camel in Action 2nd edition: >> https://www.manning.com/books/camel-in-action-second-edition > > > > -- > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2nd edition: https://www.manning.com/books/ibsen2 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
