Dear Mohamad, thanks for your reply; Sorry for my suboptimal expression: Absolutely, the use case you describe is what I have in mind. I was thinking to store the committed datatypes in different way, in fact potentially in a database and not any file. But for the first implementation I wanted to store data only in memory (for performance testing and backwards compatibility).
> I still don't understand your use case here, but I will try to explain the > situation here again as I did in the developer guide that you pointed to. > In order for the library to function properly with datatypes, it will always > need the NATIVE implementation of HDF5 datatypes, not any other > implementation. > Again, the VOL only gives you the flexibility to store the native HDF5 > datatype in whatever way you want. You could serialize it and store in a > binary blob, or whatever.. BUT the Library will always need the native > (internal) HDF5 H5T_t struct for datatypes to function properly in all the > pieces of code for datasets, attributes, etc... Yes, that is absolutely clear and not what I try to accomplish (see below the obstacle). > In order to do that, the VOL plugin must preserve a native representation for > the native datatype which can be accomplished by serializing and > deserializing the datatype struct using H5Tencode/decode. Looking at the current implementation in the native plugin: H5VL_native_datatype_get() calls H5T_encode() which is defined as a private function and should not be used by any other VOL implementation and it is expected to return. I propose to move out this logic and return a completely constructed datatype as "hid_t". Since VOL_type_commit() also receives such a type it feels natural that datatype_get() returns a userspace datatype as hid_t as well. Since apparently nobody else is interested in this detailed discussion, we can continue the discussion offline from the list. 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
