

   High,

   - I agree with Freddy about version numbers.
   - I think napi is stable enough to justify a 1.0.0
   - NXwritedata: is not to good an idea: I prefer the NXenterdata coming
     with NXdict. It creates the dataset and opens it. Then you can write 
     an arbitrary number of data slabs, compress it (when I put that in),
     add n attributes etc. My point is that NXenterdata is more flexible.
   - If it is a wish, I'am prepared to write a NXUreaddata. 
   - If do want to reduce typing when writing and reading NeXus files,
     use NXdict. That is what it is for. That is why I created it. 
   - Shouldn't NXdict be made publicly available? I'am using it now
     for writing data files for two instruments. This means, that the main
     component, the definition string parser, is working. The rest of the
     code is very straightforward. There are two options for NXDICT
     publicity: we put it in the repository. This may be a mess and confusing
     because NXDICT consists of a lot of files, as it uses various support
     components. The second option is that I do a NXDICT page for my 
     www-server, name myself NXDICT maintainer and a link is made from the 
     general NeXus page to the NXDICT page. What is preferred?
   - BTW: I think Przememk's and Nick's tcl-interface and the Browser should
     really be available as well.
   - A colleage of mine has written a F77 NeXus browser. He hit a glitch or
     may be not a glitch. NXgetnextentry returns ALL vGroups in a file. Now,
     HDF uses various support vGroups which showed up in the browser. His
     suggestion is, that NXgetnextentry should only return vGroups whose
     classnames start with NX, as required by NeXus. I did not put it in 
     because the way it is now, napi may be of use to other HDF users as
     well. Any opinions?
   - The string and attribute business is a mess. Dr. Rieman is right about 
     NXgetattribute. It should do a void pointer and not a char.
   - I'am currently doing only string attributes in my data files. But this
     could change till summer, when we start again.
   - Didn't we devise the NX_CHAR type in order to store strings in SDS's? 
     Doesn't this imply that we use NX_INT8, NX_UINT8 if we store 8-bit
     data in a SDS? I admit that I used DFNT_UINT8 for strings in my old
     data files before we decided on this. This has now been changed, they 
     are NX_CHAR from summer on. I think we have a clear strategy and a
     backwards compatibility problem, mainly here at PSI but as we are 
     providing examples, this got exported. Could be solved in a browser.
   - Concerning the four circle stuff I put up recently: I decided on an 
     NXentry for each frame. I found an artificial dimension ugly, as well 
     as my original proposal.

                                             Mark
     

      

