Re: [Orekit Developers] global configuration parameters

[Luc Maisonobe <Luc.Maisonobe@c-s.fr>]

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.

> 
> Luc
>