Hey Guozhang,
You have to accept the boolean true to support convenient programmatic
configuration (the example I showed). You have to support taking a string
to allow injecting config from a config file or external application config
system. E.g. in the case where you supply a Properties instance if that
instance was read from a .properties file the value will always be a string.
-Jay
On Thu, Feb 6, 2014 at 9:51 AM, Guozhang Wang <wangg...@gmail.com> wrote:
> 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
>
