High,

   a few news and issues about which I want to hear opinions:

   - Following suggestions from NOBUGS, NXDICT has now been updated to
     support a text replacement facility in definition strings. This means
     part of a definition string can be replaced by another alias value.
     Which is of course modifiable at run time.
   - Any dictionary file now has to have a identification string at the
     top of the file. Then Freddy can automatically identify the file as
     NXDICT file.
   BTW: shall NXDICT live in the central NeXus source repository at ISIS?
   More BTW: I would like to see Przemek's and Nick's nxpeek and browser there
   as well. 

   The next issue is compression. There was in one stage some agreement
   that the NAPI should support compression in some stage. Now, I'am ready
   to implement it, but there are a few choices to be made which  require
   discussion. HDF supports a variety of compression algorithms which can
   be configured further by parameters. Compression is applied at the writing
   stage by setting the SDS to compressed with a special function call before
   or after actually transfering data. When reading the file, decompression
   is handled transparently. The questionable issues for NAPI about this:
   * Do we drop the options quietly in our interface for the sake of 
     simplicity and use sensible defaults in the NAPI? I'll opt for that
     one.
   * Second: do we allow all compression algorithms? If we would stay with
     HDF4.* the answer would be a clear YES. But we may have to move to
     HDF5 in some near future. Compression has not been mentioned together 
     with HDF5. This implies that we might have to implement compression
     ourselves when switching to HDF5. This is easy for one of the more 
     useful compression types, the Lempel-Ziv-Welch as in gzip, because 
     there is a ready made GPL-ed library available for doing it.  So, do
     we restrict ourselves to that compression scheme in order to avoid
     trouble (I mean, a lot of extra work) when switching to HDF5?
   * So, in terms of prototypes my two suggestions look like:
     - NXstatus NXcompress(NXhandle hanlde, NXcompress type);
     - NXstatus Nxcompress(NXhandle handle);
     Both functions would be validly applied to an open SDS.

   Another issue is storing data for our four circle diffractometer.      
   At each step of the measurement, a set of angles has to be stored together
   with a histogram. This collection is what I call a frame. I'am going
   to store this as a NXdata vGroup per frame. No new entry as should be,
   but I feel the overhead is to big. This looks like:
   entry1, NXentry
           TRICS, NXinstrument 
                   ............
           sample, NXsample
                
           frame1, NXdata
           frame2, NXdata
                .
                .
                .
           framen, NXdata
   Any outcries on this one?

   I know this is long, but I want to share an info with you which I got
   out of the HDF people concerning robustness of HDF:
---------------------------------------------------------------------------
From:	SMTP%"hdfhelp@ncsa.uiuc.edu" 31-MAR-1998 17:04:48.29
To:	Mark.Koennecke@psi.ch
CC:	
Subj:	Re: compression/robustness


>  - The second question relates to robustness when writing: We need to write
>    small chunks of data continously from a program for may be a week or so.
>    What happens to the HDF file when either the program crashes during this
>    time or a power failure occurs? Is there a chance that the HDF file will 
>    be corrupted in a way, that it will not be possible to recover data at 
>    all? Can I be sure that I may append data to the file when reopened?

HDF does not have any mechanisms to keep a file from getting corrupted.
If the program crashes before the SDend, then nothing will get written to 
the HDF file.  If it crashes during the SDend, then it could be possible to 
corrupt your file if some information did not get written to the file
properly.  I do not know if you could recover your data or not, though you 
might be able to.  However, I would not count on it.

-Barbara
----------------------------------------------------------------------------
   Huuuh, this is something we have to keep in mind. I solve this by 
   reopening and closing the NeXus file for each transaction. Then the
   only corruption would happen in the unlikely event that my program dies
   in the SDend (which lives in the Nxclose).

                                            Regards,
                                                   Mark