Dear all, I was trying to provide an alternative implementation in VOL to deal with the datatypes. For testing purpose, it will simply keep the data structures in memory.
In particular the functions are problematic: - VOL_datatype_open() - VOL_datatype_get() Internally, the H5T_construct_datatype() function calls datatype_get to fetch the serialized form. This requires the datatype to be serialized in a particular form. In the Dev guide I was reading "8. The Named Datatype Pickle" https://svn.hdfgroup.org/hdf5doc/trunk/RFCs/HDF5/VOL/developer_guide/main.pdf I do not completely understand the rationale to differentiate between datatype_open and datatype_commit and relying on the serialized form: Since VOL_datatype_commit() receives the user-space datatype as "hid_t", I would have expected that datatype_open returns a hid to a proper created datatype. i.e., i could internally create the datatype with end user functions. This would give me the opportunity to store it internally in any format that suits me. In a primitive in-memory implementation, I believe the following should work: the datatype_commit() function could store a copy of the datatype in memory, then return again this copy when datype_open() is called. Looking forward to the discussion. Thanks & regards, Julian -- http://wr.informatik.uni-hamburg.de/people/julian_kunkel _______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5
