Return-Path: X-Original-To: apmail-camel-dev-archive@www.apache.org Delivered-To: apmail-camel-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 945B417FAA for ; Tue, 22 Sep 2015 13:30:52 +0000 (UTC) Received: (qmail 9690 invoked by uid 500); 22 Sep 2015 13:30:25 -0000 Delivered-To: apmail-camel-dev-archive@camel.apache.org Received: (qmail 9644 invoked by uid 500); 22 Sep 2015 13:30:25 -0000 Mailing-List: contact dev-help@camel.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@camel.apache.org Delivered-To: mailing list dev@camel.apache.org Received: (qmail 9633 invoked by uid 99); 22 Sep 2015 13:30:25 -0000 Received: from mail-relay.apache.org (HELO mail-relay.apache.org) (140.211.11.15) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 22 Sep 2015 13:30:25 +0000 Received: from server.dankulp.com (cn1.dankulp.com [64.85.173.253]) by mail-relay.apache.org (ASF Mail Server at mail-relay.apache.org) with ESMTPSA id 070BF1A009C for ; Tue, 22 Sep 2015 13:30:24 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.0 \(3093\)) Subject: Re: "advanced" label for params? From: Daniel Kulp In-Reply-To: Date: Tue, 22 Sep 2015 09:30:18 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <60F15CF9-B185-4C39-8E24-B01B991C33FB@apache.org> <36EB3614-8956-4215-9F3B-0EE64DBB3998@apache.org> To: dev@camel.apache.org X-Mailer: Apple Mail (2.3093) > On Sep 22, 2015, at 3:15 AM, Claus Ibsen = wrote: >=20 > I got a bunch of more components to use more labels. >=20 > 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 =E2=80=9CAuthentication=E2=80=9D work better? For components that = have other types authentication/login options (SSH for example) could = group them all together. Dan >=20 >=20 >=20 > On Mon, Sep 14, 2015 at 10:38 AM, Claus Ibsen = wrote: >> Hi >>=20 >> Yeah maybe advanced is a term that is maybe used in other products. = So >> I guess its after all an okay word. >>=20 >> I logged a ticket about this >> https://issues.apache.org/jira/browse/CAMEL-9131 >>=20 >> On Thu, Sep 10, 2015 at 4:00 PM, Daniel Kulp = 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. >>>=20 >>> The main reason I suggested =E2=80=9CAdvanced=E2=80=9D is that that = is what Apple seems to use in it=E2=80=99s gui for similar things. If = you are on a Mac, go to your Settings app and open up the =E2=80=9CSecurit= y & Privacy=E2=80=9D settings. There is an =E2=80=9CAdvanced=E2=80=A6=E2= =80=9D button. Likewise in the =E2=80=9CInternet Accounts=E2=80=9D. = There were a few other places I saw this as well while poking around the = various OS X applications preferences panels. >>>=20 >>> Of course, this could be something Apple has localized to my US = version of OSX. No idea. :-) No idea what MS does in Windows. >>>=20 >>> Dan >>>=20 >>>=20 >>>=20 >>>> On Sep 10, 2015, at 2:30 AM, Claus Ibsen = wrote: >>>>=20 >>>> Hi >>>>=20 >>>> 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 >>>>=20 >>>> "consumer,common,security" >>>> "consumer,common" >>>> "consumer,networking" >>>> "consumer,security" >>>>=20 >>>> And if a component is only consumer or producer then that would be >>>> implied, and you do not need to have "consumer" or "producer". >>>>=20 >>>> 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. >>>>=20 >>>> And there is also some inherited options like synchronized / >>>> exchangePattern that most people do not use, but what label should >>>> they have? >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>>=20 >>>> On Thu, Sep 10, 2015 at 2:00 AM, Jon Anstey = 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. >>>>>=20 >>>>> Cheers, >>>>> Jon >>>>>=20 >>>>> On Wed, Sep 9, 2015 at 2:23 PM, Daniel Kulp = wrote: >>>>>=20 >>>>>> I=E2=80=99m 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 =E2=80=9Ckind of works=E2=80=9D, but as new = parameters are added in Camel we >>>>>> have to keep things up to date and such. We=E2=80=99re 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 =E2=80=9Cconsumer=E2=80=9D and = =E2=80=9Cproducer=E2=80=9D and anything not >>>>>> labelled one of those is common between the two. That=E2=80=99s = a great start. >>>>>> However, while testing with some users, we=E2=80=99ve 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: >>>>>>=20 >>>>>> http://camel.apache.org/file2.html >>>>>>=20 >>>>>> There are 7 =E2=80=9Ccommon=E2=80=9D options, but for the = consumer, there are then an >>>>>> additional 51 options. It=E2=80=99s really too many to present = in a single list >>>>>> and not have the user go =E2=80=9Cwhat?!?=E2=80=9D. >>>>>>=20 >>>>>>=20 >>>>>> Would there be any objections to adding an =E2=80=9Cadvanced=E2=80=9D= label to options >>>>>> that are generally not normally used by say 90% of the use cases? = I know >>>>>> that determining whether something is =E2=80=9Cadvanced=E2=80=9D = or not can start heading >>>>>> down the path of bike shedding and the whole =E2=80=9Cwhat=E2=80=99= s advanced for one user >>>>>> isn=E2=80=99t for another=E2=80=9D and all that, but I think we = need to have something to >>>>>> help out with this. Another thought was an additional = =E2=80=9Cadvanced=3Dtrue=E2=80=9D or >>>>>> =E2=80=9Cuserlevel=3D1=E2=80=9D or similar attribute to denote = this, but the label >>>>>> functionality is already there and it seems to be perfect for = this. >>>>>>=20 >>>>>> I did quick look to see how many options we have. I = parsed/processed all >>>>>> the component json files (didn=E2=80=99t look at the models or = data format) and >>>>>> there are over 10,000 options. It=E2=80=99s 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=E2=80=A6 Longer term, this info could be used to = provide more >>>>>> useful component pages for the docs, putting the more useful = stuff at the >>>>>> top. >>>>>>=20 >>>>>>=20 >>>>>> Thoughts? Objections? Other ideas? >>>>>>=20 >>>>>> -- >>>>>> Daniel Kulp >>>>>> dkulp@apache.org - http://dankulp.com/blog >>>>>> Talend Community Coder - http://coders.talend.com >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>>=20 >>>>> -- >>>>> Cheers, >>>>> Jon >>>>> --------------- >>>>> Red Hat, Inc. >>>>> Email: janstey@redhat.com >>>>> Web: http://redhat.com >>>>> Twitter: jon_anstey >>>>> Blog: http://janstey.blogspot.com >>>>> Author of Camel in Action: http://manning.com/ibsen >>>>=20 >>>>=20 >>>>=20 >>>> -- >>>> Claus Ibsen >>>> ----------------- >>>> http://davsclaus.com @davsclaus >>>> Camel in Action 2nd edition: >>>> https://www.manning.com/books/camel-in-action-second-edition >>>=20 >>> -- >>> Daniel Kulp >>> dkulp@apache.org - http://dankulp.com/blog >>> Talend Community Coder - http://coders.talend.com >>>=20 >>=20 >>=20 >>=20 >> -- >> Claus Ibsen >> ----------------- >> http://davsclaus.com @davsclaus >> Camel in Action 2nd edition: >> https://www.manning.com/books/camel-in-action-second-edition >=20 >=20 >=20 > --=20 > Claus Ibsen > ----------------- > http://davsclaus.com @davsclaus > Camel in Action 2nd edition: https://www.manning.com/books/ibsen2 --=20 Daniel Kulp dkulp@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com