Peter Colberg writes:
> Abstractions are very hard to get right. To day I have not seen a
> single C++ interface to HDF5 that is useful beyond the initial goals
> at its conception.
I am tempted to make some mean comments about C++, but I can just
force myself to shut up ;-)
> While it is important to have high-level interfaces that guide new
> H5MD users (e.g., pyh5md), it is equally important to support those
> users that write high-performance programs using the HDF5 API.
Another nice illustration for the importance of practicalities.
In this particular case, we have
1) String data in trajectories are usually small in amount (I have yet
to see a use for time-dependent string data), so efficiency of storage
and access is of secondary importance.
2) In high-level languages such as Python, dealing with any kind of
string
data is easy enough.
The priority in defining the layout for string data should thus be to
reduce the barrier for dealing with H5MD in low-level languages. My
own experience is C, which makes me prefer variable-length strings,
but of course there are other languages to take into consideration.
> Keeping the choice between fixed- and variable-length strings will
> simply mean that many writers and readers will not be interoperable,
> even if they use the same domain-specific data.
Here are the pros and cons as I see them:
Mandatory string type (either fixed or variable)
+ simplifies software for reading H5MD
User's choice of string type
+ simplifies software for writing H5MD
- likely to create incompatibilities because people will write
H5MD readers with a specific "dialect" in mind
Personally that makes me favor a mandatory single string type.
Konrad.