Hello Evan,
I find it a bit counter-intuitive to cache data inside the factories. I would find it more logical to cache the data in the providers instead.
This allows to clearly separate the data loading from the data use.
I guess that the data is cached in the factories because some factories transform the data before caching it ? If the transformation is computation-intensive,
then the current design makes good sense.
My ideas are too messy to be written down right now. I am toying with the idea of Java Services, as described here :
https://docs.oracle.com/javase/tutorial/ext/basics/spi.html
I believe I have found something that would work for me, but I am still trying to make sure it could accommodate the other use cases. I think this
is the kind of topic where a live brainstorming session, in person, would be much more efficient than mail. Which is one of the many reasons why I am looking forward to Orekit Day !
Kind regards
Yannick
From: orekit-users-request@orekit.org [mailto:orekit-users-request@orekit.org]
On Behalf Of Ward, Evan
Sent: Monday, November 13, 2017 3:30 PM
To: orekit-users@orekit.org
Cc: orekit-developers@orekit.org
Subject: Re: [Orekit Users] design of the DataProviders
On Mon, 2017-11-13 at 12:16 +0100, MAISONOBE Luc wrote:
"JEANDROZ, Yannick [FR]" <yannick.jeandroz@airbus.com> a écrit :
[snip]
I have started thinking about possible refactorings of the model data
management. I have a somewhat similar behaviour somewhere else in my
software,
and I have used a dependency inversion based on Java services to solve it. So
far, it seems to work quite well (but my software is not that big yet, so it
might be a bit early to tell). Maybe something like this could be implemented
for orekit data management ? I would gladly share a very basic draft
of my ideas
if it can be of any help.
Sure! We can speak about this on the developers list (and also during
the Orekit day at the end of the month!).
Yannick, I'm interested in hearing your ideas. I've run in to the same issue when trying to use different EOP data sets within the same Orekit application. My thought is to:
1. Make the DataProviderManager (DPM) instaniable.
2. Make all the static factories (TimeScaleFactory, FramesFactory, etc.) instantiable and take a DPM in the constructor.
3. Ensure that for every contructor/method in Orekit that uses one of the static factories there is an equivalent method that receives the factory or the factory-created object as a parameter instead.
The existing static factory methods could be retained to make it easier for new users or simple applications.
Loaded data would still be cached in each of the factories, but the user application would now have more control over where the data is used. For example, application could use one TimeScaleFactory for the entire application to match the
current behavior, or one TimeScaleFactory per thread to match Yannik's use case, or something more complex that makes sense for the specific application.
Here is an example of what the code would look like:
DataProviderManager dataSet1 = new DataProviderManager();
dataSet1.addProvider(new DirectoryCrawler("C:/dataset1"));
DataProviderManager dataSet2 = new DataProviderManager();
dataSet2.addProvider(new DirectoryCrawler("C:/dataset2"));
TimeScaleFactory tsf1 = new TimeScaleFactory(dataSet1);
TimeScaleFactory tsf2 = new TimeScaleFactory(dataSet2);
TimeScale utc = tsf1.getUTC(); // using original data set
TimeScale utcPlusHalf = tsf2.getUTC(); // using modified data set
Comments and criticisms welcome.
I agree with Luc that this would be a good topic to discuss at the Orekit Day.
best regards,
Luc
Thank you for your time.
Yannick Jeandroz
Yannick Jeandroz
TESOA2 - Flight Dynamics
T +33 (0)5 62 19 51 71
E yannick.jeandroz@airbus.com
www.airbusdefenceandspace.com<http://www.airbusdefenceandspace.com/>
[AirbusDS]