Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

container-independent access #21

Open
KrisThielemans opened this issue Dec 4, 2022 · 1 comment
Open

container-independent access #21

KrisThielemans opened this issue Dec 4, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@KrisThielemans
Copy link

KrisThielemans commented Dec 4, 2022

At present, I believe the user has to know if the stored data is binary or HDF5, and instantiate the corresponding class. That's efficient but also very inconvenient. It would certainly be nice to be able to write some client-code that does not depend on the container-type. (Edit: I see that there are abstract classes in protocols.h already, so possibly the only thing that's necessary is a factory that determines the container-type given a filename)

@johnstairs
Copy link
Member

Yes, the readers and writers inherit from common abstract classes so once instantiated, you can have code that works independent of the file format.

But we could generate factories. For readers, we could use the file extension or peek at the first few bytes. In addition to file names, the binary readers and writers support stream-like objects, but HDF5 does not support this, so I guess the factory would be based on a file name. For creating writers, you need to know what format you want, so there is probably less value in generating those.

@johnstairs johnstairs added the enhancement New feature or request label Dec 5, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants