There have been several cases lately
where we are being burned by having used boolean values for properties,
headers, ... In particular, things like
are problematic for a few reasons.
- First we seem to have this tendency
to specify them in the negative. For example unpack=false is the
default way we want things. That approach made sense in the context
of the day but today it is just hard to deal with the double negative.
- It is not always clear what the property
is controlling. unpack, for example, is somewhat cryptic.
- Perhaps the most interesting issue
relates to extensibility. Eclipse-LazyStart: true/false has only
two possible values. Recently there has been some discussion about
adding an eager mode. Ignoring the details of that request and assuming
we did want this, with only true and false for Lazy start, we would have
to add another header for eager mode.
An alternative would be to avoid headers,
arguments, properties etc that have boolean values. Instead of unpack
= true/false, use something like form=jar/dir. Eclipse-LazyStart
would be something like Eclipse-BundleStart: lazy/manual/eager. This
approach is more extensible and seems easier to usnderstand. Note also
that these headers can have additional information provided as attributes
or directives in the standard OSGi manner.
p.s., note that this thinking should
also be applied to any OSGi RFCs we put forward.