NXUenterdata

[Ray Osborn]

Thanks to Mark for the quick reply.  I'm sorry to be rehashing a debate we
had a while ago, but I think it is worth returning to it one last time.  The
reason is that I have been reluctant to begin serious NAPI programming
because of the fear that my programs will become seas of NXmake/open/putdata
routines.  If I have am hesitant, I feel sure that other less committed
users will be put off.

I will respond to Mark's comments here but other opinions will be useful,
especially if you've done a lot of NAPI programming already.

>   There is a reason why I made NXenter as it is. I actually have a routine
>   which does a write with units somewhere. When using it I found, that it
is
>   not general enough. Quite often I put a piece of data with it and then
had 
>   to open the SDS again in order to write an additional attribute or to
>   recover the ID's needed for linking. This is why I stopped at NXenter.

Why would the SDS need to be reopened?  Can't it stay open until you try and
open another SDS?

>
>   Now: the NXopengroup, NXmakegroup, NXopendata issue:
>   There was a conscious design decision to make it look much like
navigating a
>   filesystem:
>       NXmakegroup --> mkdir 
>       NXopengroup --> cd 
>       NXmakedata  --> well, this is a make file which is usually done with
>                       fopen.
>       NXopendata  --> fopen()

I understand that this analogy was considered useful when we first designed
the API.  However, I believe that we have now become imprisoned by it
unnecessarily.  I am not asking that we get rid of NXmake/opendata, since
there are times when they will be useful, just that it should not be
necessary to call them all if we don't want to.

>   NXmakedata and Nxopendata were kept separate in order to prevent
inadvertly
>   creating SDSs with slightly misspelled names and without an error
return.

I don't really understand this point; aren't you more likely to make a
spelling mistake if you have to write the name three times instead of once? 
I am arguing that we call NXputdata to create, open and write the SDS with
whatever name we choose to give it.  We might make a spelling mistake, but
then we might make a spelling mistake with NXmakedata with the same
consequences. 

> 
>   Do we want to drop this semantic in napi?  I think this needs a
conscious
>   decision. 
>

I repeat that I am not asking that we drop the NXmake/opendata routines
altogether.  There are many occasions, particularly when reading data, that
we will need to call NXopendata before calling NXgetdata, so we need to keep
it. I am just asking for a way to avoid using them all when I am doing a
standard write operation. 

Apart from purely philosophical considerations, is there a practical reason
why we can't make the operation of NXputdata as follows:

1) Check to see if SDS exists.  If not (and the NeXus file is open for write
access), make it.  If there is an error in creating it, return with the
error
2) Check to see if the SDS is open.  If not, open it.  If there is an error
in opening it, return with the error.
3) Write the data, leaving the SDS open for subsequent NXputattr calls.  If
there is an error writing it, return with the error.

If we did this, I would like the units attribute installed as an optional
final argument to NXputdata for the reasons I have given before.

>   There is a general point however, that handling NeXus files seems to be
to
>   complicated. Well, I found that a lot of repetitve code was necessary
and
>   so I invented Nxdict to make it simpler. It works well for me, but I
collect
>   that my aproach is unpopular. 

I don't think the problem is that NXdict is an unpopular concept.  It could
prove to be a major labour-saving tool for NeXus.  It's just that I want
experience with the regular NAPI before deciding when I need to try a new
approach.  I want to learn to walk before I try to run.

Any other opinions please?

Ray
-- 
Dr Ray Osborn                Tel: +1 (630) 252-9011
Materials Science Division   Fax: +1 (630) 252-7777
Argonne National Laboratory  E-mail: ROsborn at anl.gov
Argonne, IL 60439-4845