I don't think, we should fix our API to one single XML serialization API.
I may agree...
And XStream needs so many jars (ugly).
It only needs the xstream.jar AFAIK
I would suggest to write an interface called XSGSerializable (or something like that), that has a method, that returns a string (maybe XML), that contains every information, that is necessary to recreate the Node instance. This way a Model would only need very few information like model type, model resource, skin, current animation and anim-time, etc. If you would naively serialize the Model, you would need to serialize any sub-Node of it. Additionally the XSGSerializable interface would need to have a method, that tells the serializer if it is a leaf or not. E.g. a Model would be a serialization-leaf, while it is not a SceneGraph Leaf Node.
There is a Scribable interface for the old terrain implementation that looks a bit like this and I think the java API has this in form of the Externalizable
interface. The only downside is, that it more or less links the serialized representation to the class and not to the serializer.
I think I will toy a bit with xstream without using annotations and configure the fields and mappings in the serializer class to avoid a direct dependency. Something that is needed in any case is rework of some classes to correctly specify transient fields (my first try serialized my whole application
) and implement some readResolve()-method on the nodes like described here
. If once done fully, this would have the benefit of being able to using standard JDK serialization as well.
And for the curious, I started a terrain browser to help me debug my terrain code
, but think it would much more useful to have a scenegraph editor and for that a scene graph serialization is essential.