NXUenterdata

[c.m.moreton-smith at rl.ac.uk]

Re: Ray's first message on this, here are some design principles which
can help but expressed via the file system analogy.

The current API is what I would call a "State-based" system, i.e., the
state of the API depends very much on what you've done before, this is
good for programmers writing something like a browser. You only need to
(for example) open a group once in each session and so it is efficient. 

In file system terms it is something like:

	cd entry1
	cd instrument
	cd temp
	echo $var1 $var2  $var3  > mydataset
	cd ..
	cd ..
	cd ..

or in VMS

	SET DEFAULT [.ENTRY1]
	SET DEFAULT [.INSTRUMENT]
	SET DEFAULT [.TEMP]
	copy sys$input mydataset.sds
	var1 var2 var3
	^Z
	SET DEFAULT [-]
	SET DEFAULT [-]
	SET DEFAULT [-]

Would we normally do this in real life? - probably not

Mark's dictionary system is heading the other way to a "State-less"
system but could go a bit further and also provide Ray's NXputdata.
Stateless systems are usually easier to understand for more casual users
(they don't have to remember where they are or what order to do things
in and hence can't get the order wrong). In a stateless system, this is
what we would do:

	echo $var1 $var2  $var3  > entry1/instrument/temp/mydataset

or on VMS

	copy sys$input [.ENTRY1.INSTRUMENT.TEMP]mydataset.sds
	var1 var2 var3
	^Z	

the names are a bit long here so could we do better? - once again, yes,
we could use a logical name on VMS or a environment variable on Unix.
e.g.

	echo $var1 $var2  $var3 > $TEMPD

or on VMS

	copy sys$input TEMPD:
	var1 var2 var3
	^Z

the logical name table or Unix environment is the equivalent of Mark's
dictionary.


Can this work for NeXus?

In Open GENIE we went for a one shot interface, i.e. stateless, it's a
bit harder to program.  For example if the user writes to a different
group you have to close down and re-open another group or groups at the
beginning of the next command (or always open up the whole tree and
close it each time).

>From the point of the user, especially with a dictionary of short names
available there is no competition, for the implementers it's best to
bite the bullet and provide what the users are going to want, here I
have to support Ray - I've never programmed to the NAPI interface, but
I've written several nexus files with one line commands from GENIE!

Two other things we learnt, you don't need any explicit group open/close
statements, just

(1) A "/NEW" flag (Ensures that you say when you really want to create a
new group to avoid typo's)

(2) An "/OVERWRITE" flag, should you really want to overwrite data,
probably not the default either.

We could implement NeXus with four commands:

NXopenfile and NXclosefile to allow NeXus to NeXus file copying with
separate handles and NXputentry and NXgetentry.

we already do this with the Put and Get commands in Open GENIE. I'm not
suggesting we make Open GENIE part of NeXus - but the point is an
interface like this demonstrably does work, the hardest work is in
writing the dictionary parser and Mark has already done this so the bits
are present to go the whole way.

Chris