I am in the process of adding support for retrieving
the final file image for an in-memory file. This would
extend the existing nc_open_mem functionality.
I would like comment on this proposal.
This involves several changes.
1. nc_open_mem() would now allow the NC_WRITE mode flag
so a chunk of memory can be passed in and be modified
2. nc_create() would now allow the NC_INMEMORY flag to be set
to cause the created file to be kept in memory.
3. the ability would be provided to obtain the in-memory contents
of a file at the point it is closed using a new function
nc_close_mem(int ncid, size_t* sizep, void** memory)
Note the following.
1. If nc_open_mem is called with NC_WRITE, then a copy of the incoming
memory would be made internally (dictated by HDF5 functionality).
If instead, the file is read-only, no copy would be made.
2. The memory returned by nc_close_mem would be a COPY of the current
contents if the original was writeable (again HDF5 forced).
I also have a couple of thoughts.
1. Instead of nc_close_mem, I could separate out the memory extraction
from the close operation. Hence one would call something like
nc_get_mem() and then nc_close() instead of nc_close only.
I prefer the nc_close_mem solution, but can anyone provide a
use case where the separate functions is better?
2. I could always make it so that the incoming and extracted memory
chunks were copies. This would mean that read-only opening
a memory chunk would pay the copy cost when it did not have to.
But the always copy soln might be simpler for the user to understand
and use.
Note that this is all preliminary and is subject to change if,
for example, I cannot get some piece of functionality to work.
=Dennis Heimbigner
Unidata
