I made a typo in my previous email, I meant to say "not allowing", i.e. if
a config' type is Boolean, do not accept "true" as the value.
On Thu, Feb 6, 2014 at 8:30 AM, Jay Kreps <jay.kr...@gmail.com> wrote:
> Guozhang,
>
> In spirit I agree with you, but it is really annoying if I can't say
> props.put("config.a", 45)
> props.put("config.b", true)
>
> This is especially true because config will actually come from elsewhere
> and may have the appropriate type so in reality you end up with
> props.put("config.a", Integer.toString(theValue))
> and the error is usually pretty confusing because it is like
> "Invalid value true, not a boolean!"
>
> Since the type is specified I can't think of any corner case with confusing
> behavior.
>
> -Jay
>
> -Jay
>
>
> On Wed, Feb 5, 2014 at 5:30 PM, Guozhang Wang <wangg...@gmail.com> wrote:
>
> > I like the helper function in all except in parseType: is it better to be
> > restrict about types, i.e. now allowing "true" if the type is really
> > Boolean?
> >
> >
> > On Wed, Feb 5, 2014 at 5:06 PM, Joel Koshy <jjkosh...@gmail.com> wrote:
> >
> > > Overall, +1 on sticking with key-values for configs.
> > >
> > >
> > > > Con: The IDE gives nice auto-completion for pojos.
> > > >
> > > > Con: There are some advantages to javadoc as a documentation
> mechanism
> > > for
> > > > java people.
> > >
> > > Optionally, both the above cons can be addressed (to some degree) by
> > > wrapper config POJOs that read in the config. i.e., the client will
> > > provide a KV config, but then we (internally) would load that into a
> > > specific config POJO that will be helpful for auto-completion and
> > > javadocs and convenience for our internal implementation (as opposed
> > > to using getLong/getString, etc. which could cause runtime exceptions
> > > if done incorrectly). The javadoc in the pojo would need a @value link
> > > to the original config key string if it is to show up in the generated
> > > javadoc.
> > >
> > >
> > > > show you the value of the constant, just the variable name (unless
> you
> > > > discover how to unhide it). That is fine for the clients, but for the
> > >
> > > Figuring out a way to un-hide it would be preferable to having to keep
> > > the website as the single source of documentation (even if it is
> > > generated from the javadoc) and make the javadoc link to it. I tried,
> > > but was unsuccessful so unless someone knows how to do that the above
> > > approach is the next-best alternative.
> > >
> > > > server would be very weird especially for non-java people. We could
> > > attempt
> > > > to duplicate documentation between the javadoc and the ConfigDef but
> > > given
> > > > our struggle to get well-documented config in a single place this
> seems
> > > > unwise.
> > > >
> > > > So I recommend we have a single source for documentation of these and
> > > that
> > > > that source be the website documentation on configuration that covers
> > > > clients and server and that that be generated off the config defs.
> The
> > > > javadoc on KafkaProducer will link to this table so it should be
> quite
> > > > convenient to discover.
> > >
> > >
> >
> >
> > --
> > -- Guozhang
> >
>
--
-- Guozhang
