Hi Julian,
> >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. Right, but you can use the public version of this function: https://www.hdfgroup.org/HDF5/doc/RM/RM_H5T.html#Datatype-Encode And the decode: https://www.hdfgroup.org/HDF5/doc/RM/RM_H5T.html#Datatype-Decode > >I propose to move out this logic and return a completely constructed >datatype as "hid_t". We can't return an hid_t directly from the plugin to the user, as the HDF5 library (the higher level VL layer) takes whatever structure returned from the plugins for objects and wraps it with another structure to include some more information about the plugin this object is being created with and a reference count on that object, and then creates the hid_t on that higher level struct. So we can't have plugin do all of that. >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. Sure I'm happy to continue this discussion offline, and maybe schedule a quick call to explain the quirks with this :-) Thanks, Mohamad > >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 _______________________________________________ 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
