Hi, 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, Luc
I'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.
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.
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.
Regards, Evan