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
>
