[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Orekit Developers] global configuration parameters
- To: orekit-developers@orekit.org
- Subject: [Orekit Developers] global configuration parameters
- From: Luc Maisonobe <Luc.Maisonobe@c-s.fr>
- Date: Fri, 06 Apr 2012 16:33:33 +0200
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111114 Lightning/1.0b2 Icedove/3.1.16
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 ?
Luc