Sketch for extension of reader architecture

4 views
Skip to first unread message

Harald Scheirich

unread,
May 14, 2015, 12:04:27 PM5/14/15
to openSurgSim
After a message from Ricardo Ortiz that showed the need for extending our architecture to enable reading other file formats beside .ply here is a preliminary idea that can support extension. We came up with a possible solution it has two main branches both with their respective advantages and disadvantages

Currently all the actual loading is done by the virtual doLoad(std::string filename) function in each subclass of Asset, we could extend Asset for all Mesh related classes to support doLoad(std::string filename, MeshReader reader) MeshReader does not exist yet, but the current PlyReader would become a MeshReader. This now enables the actual load to be done by the reader class passed into the function rather than the fixed ply reader.

From here there are two possibilities:

a) Reuse the existing delegate classes
In this case a lot of the interface in the PlyReader will be represented in the interface of the MeshReader, e.g. all the delegate registration, all the callback mechanism, passing data adresses to the reader as locations for data to be deposited. While this interface was informed by the ply.c architecture it is generic enough to suit most needs. But for a new reader class a VTK reader it might not be the best interface. The advantage of this approach is though that all the readers, new and old can use the same delegates. Reuseability at the cost of an inconvenient interface between Reader and Delegate

b) Each reader has it's own delegate
In this case each reader would have to supply a set of delegates to be used for pushing the file data into the appropriate classes, Then each Reader/Delegate could have a specific architecture that fits the needs of the Reader, the cost here is that each reader would need a set of deletages for each datatype that needs to be read.

We have working mechanisms for registration, object factories and such, so finding the correct reader for each filetype can be implemented easily in the current code base. 

Comments, Ideas, other options ? 

Harry
--
Harald Scheirich
Principal Software Engineer
Simquest Solutions Inc. 
Reply all
Reply to author
Forward
0 new messages