[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] boolean properties etc

I agree that true/false values for a property/manifest header is not 
future proof. In the OSGi specs we try to use multivalues so that new 
values can be defined in the future.

BJ Hargrave
Senior Technical Staff Member, IBM
OSGi Fellow and CTO of the OSGi Alliance
hargrave@xxxxxxxxxx
Office: +1 407 849 9117 Mobile: +1 386 848 3788



Thomas Watson/Austin/IBM@IBMUS 
Sent by: equinox-dev-bounces@xxxxxxxxxxx
09/29/2006 08:20 AM
Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
cc

Subject
Re: [equinox-dev] boolean properties etc







We are in the process of proposing a lazy-start mechanism for the next 
release of OSGi.  When/If this gets added to the OSGi specification the 
Eclipse-LazyStart header will not be used.  Currently we are thinking of 
adding a Bundle-StartPolicy header.  To start with we will only specify a 
"lazy" policy but this leave us open to other types of "start policies". 
Jeff, is this a more acceptable approach for the header and its values? 

For more details on the lazy-start policy being proposed to OSGi see 
http://bundles.osgi.org/Design/LazyStart 

Tom 




David M Williams/Raleigh/IBM@IBMUS 
Sent by: equinox-dev-bounces@xxxxxxxxxxx 
09/28/2006 10:40 PM 

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>


To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx> 
cc

Subject
Re: [equinox-dev] boolean properties etc









Makes sense to me. 

Another possible advantage of enumerated attribute values is that there 
might be some cases where 'systemDefault' would be a good option, 
so that some "meta data" could specify "use form=jar/dir unless otherwise 
specified". 
I don't know if that particular example is valid, or how many cases this 
would be needed or make sense ... so, take with a grain of salt. 
But, I've actually seen this anti-pattern? a lot with "user preferences" 
... the intial tendancy is often to think of some user preference as "on 
or off" but 50% of the time 
the next release reveals more cases ... "not specified by user" being an 
obvious third choice. 

But, for manifests, couldn't "true/false" usually be deprecated, and 
future versions be spec'd as multivalued (and 'true', 'false' be assigned 
to one of the new states, for backward 
compatibility?). But I do agree, its just more meaningful to spec what you 
mean :) 






Jeff McAffer <Jeff_McAffer@xxxxxxxxxx> 
Sent by: equinox-dev-bounces@xxxxxxxxxxx 
09/28/2006 11:11 PM 

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>



To
equinox-dev@xxxxxxxxxxx 
cc

Subject
[equinox-dev] boolean properties etc











There have been several cases lately where we are being burned by having 
used boolean values for properties, headers, ...  In particular, things 
like 
      unpack=true/false 
      Eclipse-LazyStart: true/false 
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. 

Thoughts 
Jeff 

p.s., note that this thinking should also be applied to any OSGi RFCs we 
put forward._______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev