Boost seems to have/get a powerful object serialization library:
http://www.boost.org/doc/libs/1_39_0/libs/serialization/doc/index.html

<-- they claim to be able to serialize/deserialize objects that contain pointers to other objects and to serialize stl containers, version control per class definition, portability issues (big/little endian), no change to classes that should be serialized.
If the library holds what it promises, then it will provide solutions for many of our requirements.

First ideas about how to solve this issue (in German)

Ok, Jochen and I agreed on a first implementation with the following ideas:

• a central XML file is written using TinyXML
  • this file contains only parent-child relations of datatreenodes from a data storage and references other, separate files containing serialized basedata and propertylist objects
• basedata and propertylist objects are serialized using "Serializer" objects
  • these objects are registered with the ITK object factory and found by their name, which is like "SerializeImage" and "DeserializeImage"
  • we want to try if factory registration can be done via static objects
• the XML description along with all other files should be zipped
  • advantage is that human users can open such files and inspect/use the contents
  • a seemingly nice library for zipping is Info-ZIP (http://infozip.sourceforge.net) with its permissive license
    • my first attempt will be to rip out everything needed to create and read a .zip file from the source code and create CMake files for that (in a separate module)

A couple of sub-bugs will be opened for the single implementation tasks

Attached the updated mindmap

On Marco's suggestion I considered Qt for reading/writing zip files.

Qt source code comes with a class QZipReader. However, this is a library private implementation with huge warning comments that the headers/impl is subject to change from version to version or even subject of complete removal.

Copying these files into a MITK module is not an option, since it is LGPL and I guess this would be derivative work.

Added a couple of bugs for single tasks in implementing scene serialization

Updated the mindmap with a couple of things that came up during prototype implementation (and after discussion with Jochen):

We decided how to report errors to the application:

• return a list of all nodes with failed BaseData serialization
• return a list of all properties and their nodes with failed Property serialization

We decided on versioning:

• one reader class per object
• this reader handles versioning
• a common reader super class can provide convenience methods is necessary
• should a certain property ever be removed, a reader for this property must be kept. This may report isLegacy() and return a whole list of properties instead of a single one (this would happen to closely remodel the influence of the old property)

We found that a question needs discussion:

• what is the exact role of geometries in MITK?
• is this consistent through all data classes?
• should geometries be serialized?
  • or is this part of the data format itself?

Our suggestion on the geometry question is:

• geometries should describe placement of a data object in space
• mappers should always transform data through geometries before rendering
• anything that behaves differntly should be changed

Added RFD flag: comment #7 needs to be discussed.

The geometry issue was discussed in an MITK meeting:

• geometries are treated differntly by different writers
• before rendering or knowing world positions of data, they should generally be run through their geometries
• thus it is necessary to serialize geometries, too
• all writers/readers, which handle data differently must be changed

Maybe http://code.google.com/p/libarchive/ could be an alternative to Info-ZIP. It supports multiple archive formats and has a BSD license.

Another serialization lib, found by Sascha:
http://code.google.com/p/protobuf/

The complete work package cannot be solved until 1.0. However the serialization is already functional and the test cases are flagged as relevant for 1.0.

Scene serialization is working fine, what are open points in this bug?

Removing party keyword because this seems to be a meta bug and so no bug which can be solved during a bug squashing party.

(In reply to comment #13)

Scene serialization is working fine, what are open points in this bug?

Removing party keyword because this seems to be a meta bug and so no bug which
can be solved during a bug squashing party.

Have you checked the attached mindmap? I would also say it is ok as it is now, but perhaps somebody can re-assess possible improvements and open specific enhancement tickets (if needed).

Resetting all bugs without active assignee flag to "CONFIRMED". Change status to IN_PROGRESS if you are working on it.

Old ticket does not help progressing. The feature basically works as it is.