Re: [Orekit Developers] global configuration parameters

[Thomas Neidhart <thomas.neidhart@gmail.com>]

On 04/06/2012 04:43 PM, Luc Maisonobe wrote:
> Le 06/04/2012 16:33, Luc Maisonobe a écrit :
>> Hi all,
>>
>> As part of the work concerning thread safety (see issue
>> <https://www.orekit.org/forge/issues/3>), we will need to provide
>> another global configuration parameter to users with a default value.
>>
>> There are a number of similar parameters already used in various places
>> in Orekit. For example users can provide their own names for gravity
>> fields files or use the default ones, they can provide their own names
>> for JPL ephemerides or use the default ones, they can provide their own
>> names for UTC-TAI files or use the default ones ... The new parameters
>> would not be names but a few numbers (default number of slots in
>> thread-safe caches, max range to be stored in cache ...). I guess other
>> parameters could be added later on as Orekit evolves.
>>
>> As the number of such configuration parameters increases, having them
>> spread across the library seems awkward to us.
>>
>> We would like to gather all these parameters in a utility class (say
>> OrekitConfiguration or OrekitDefaults) with a few static methods:
>> getEigenSupportedNames(), getDefaultCacheSlots() and the corresponding
>> setters.
>>
>> The existing factories (GravityFieldFactory, TimeScalesFactory and so
>> on) would use the getter to configure themselves.
>>
>> If the user is happy with the hard-coded defaults
>> ("^eigen[-_](\\w)+_coef$" for the Eigen gravity files for example), then
>> would not do anything (just as they do nothing now) and the getter would
>> by default return some values. If the user prefer to change some names
>> or numbers to match specific needs, they would call associated setters
>> at application startup so the factory can retrieve the value when needed.
>>
>> The only difference between what is done now and what would be done if
>> we implement this, is that the default settings would all be in one
>> class rather than in several factories.
>>
>> When future new parameters would be added (just as what I want to do now
>> for the thread-safety fix), new static methods would be made available
>> in this class and everybody would now were to look as new versions are
>> released.
>>
>> What do you think about this idea ?
> 
> I forgot to say that large configuration or Inversion Of Control
> frameworks like Spring, PicoContainer or Guice are clearly not an
> option. Orekit has only one dependency for now (Apache Commons Math) and
> is a low level library, so it should not bring a bunch of dependencies.
> Such frameworks are a must at application level, but they are not suited
> for low level components.
> 
> At application level, we expect users to use these frameworks if they
> want, and they can use them to call the simple setters of our little
> configuration utility class.

+1

Thomas