Evan Ward <evan.ward@nrl.navy.mil> a écrit :
Hi,
Hi Evan,
MAISONOBE Luc wrote:I would propose to follow Apache Commons Math policy and limit our use of Serializable to some basic classes where it makes sense (typically data containers like orbit, attitude, date, transforms, body shapes, geodetic point ...) and remove it for complex cases like Propagator or AttitudeProvider. What do you think about this change? best regards, LucI'm all for simplifying the API. IMHO even the few remaining serializeable classes present some difficulty for defining the "correct" behavior.One issue is that Frames use large datasets to compute the transformations. If the whole dataset is serialized then the resulting file size becomes impractical. If only some identifying information about the frame is serialized (e.g. a Predefined for a FactoryManagedFrame) then the de-serialized frame can be different from the original frame depending on which configuration data (EOP, JPL ephemerides) is used. The current implementation uses a mix of the two approaches that makes it hard to determine which data will be used.
There are two reasons for the current behaviour for FactoryManagedFrames. The first reason was that we really need to have a single root hierarchy, so when deserializing a frame we have to plug it in the existing frame, we cannot let it create an independent tree by deserializing all its ancestors. The second reason was that we wanted to avoid creating too many copies of similar frames. These instances are not singleton per se (and don't need to) but they have some characteristics of singleton, only for memory consumption purposes. However, since now the data are hold by TimeStampedCache which is not serializable and the same cache can be shared by many instances (even in different thread, as it was created specifically for this purpose), the second reason about memory consumption problems could be ignored. So you are right, it is worth looking at what we want to save.
I just looked at FactoryManagedFrame and noticed that we replace the raw deserialized object by recreating it from the key (see the readResolve method in FactoryManagedFrame. However, we serialized everything, which is a mistake. We should use a proxy object here too. I'll fix it.
Another issue is the additional complexity that serialization adds implementations of the interfaces. For example, if we decided to add a Geoid class (implements BodyShape) would it write out 5 MB of gravity coefficents, or does it get a back door for serialization to use to set the coefficients? These kind of design decisions will make it harder to extend Orekit.
You are right, thanks for pointing this out. So the problem appears for all things that are related to models. I'm not sure we are going to solve everything in a single sweep. I would prefer to give a try to a few things (like Propagator) and see if this works for everyone. You can also look at BodyShape at the same time if you have this kind of use. I don't think we will do a thorough check of all our interfaces.
To sum up, I think persistence should be in a separate layer from Orekit because the desired behavior can be different depending on how Orekit is used. If people need quick and dirty serialization use XStream ( http://xstream.codehaus.org/ ) which doesn't need the Serializeable marker interface to serialize an object.I'm coming at this from the "save state to a file" perspective. I'm interested in hearing what other people think, especially from a distributed computing perspective.
best regards, Luc
Regards, Evan
---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.