Editing Sandbox (section)

=Brainstorming=
* [http://sourceforge.net/forum/forum.php?thread_id=1579057&forum_id=552249 Madagascar file bundles]
* [http://reproducibility.org/rsflog/index.php?/archives/13-Guide-to-RSF-programs-sfdd.html Byteswapping option for sfdd]
* [http://reproducibility.org/rsflog/index.php?/archives/122-Increasing-the-size-of-the-Madagascar-community.html Google bombing for Madagascar; interface to industry]
* [http://sourceforge.net/mailarchive/forum.php?thread_name=20060908165243.57253.qmail%40web34208.mail.mud.yahoo.com&forum_name=rsf-devel Parallelization API]
* [http://reproducibility.org/rsflog/index.php?/archives/62-Nick-Vlad-on-RSF-and-XML.html Using XML in RSF headers]; 
** Later: [http://sourceforge.net/mailarchive/message.php?msg_name=20060926210620.60597.qmail%40web34207.mail.mud.yahoo.com Author's own repudiation of the AJAX part of the previous proposal] (other parts still stand). 
** Author's suggestion for an alternative to XML (from a private email to Sergey): "What does one do with XML? Read it with a program, right. XML is good if you can make no assumptions whatsoever about which language the said program was written in, and what that program is (could be a web browser of sorts, could be an Erlang application, could be a Python script, could be a C++ compiled binary). Then to deal with uncertainty you spend resources on insurance, using a verbose, completely unambiguous data description. So XML is the "canonical" approach. But what if one goes for the agile "worse is better" and notices that header file I/O costs nothing, so it can be done all in Python , regardless of what the language of the computational engine of the program. Then it does not make much sense to write from Python to XML, then read it back -- just write the header in Python! This, incidentally, is what the current syntax of RSF headers is. I realize that what I wanted XML for was delimiting in some way what was written to a header by a program and what was written by another. This way one would not get five trailing dimensions of length one because at some point the file was a five dimensional cube, while at the same time retaining meaningful dimensions of length one (i.e. the crossline for an inline extracted from a dataset). Rewriting to the header the complete description (n,o,d,unit,label) of the axes of the output for each program , all "kept together" by some syntax, would make it much easier to figure out what was actually done to the cube, and would avoid having to parse the entire file -- just read the last structure. JSON  ( http://en.wikipedia.org/wiki/Json ) is designed to be an alternative to XML that is step in this direction (it is valid Javascript, and not at all far from Python), and of course, one can use Python syntax for keeping some variable values together, and do the I/O all in Python. I think this is what Lisp does and what the whole "data is code/code is data" thing is about."
* From the Sergey-Reg Beardsley email exchange on rsfuser in Jul 2006: add to each history record Madagascar, OS versions
* To have a consistent user interface, certain types of inputs and outputs should be standardized. A small beginning has been made by giving the verbosity option the same name everywhere. More meaningful issues would involve:
** having all frequencies in Hertz
** deciding whether all offsets should be half offsets or full offsets
** FFT sign conventions (- for FFT forward in time, + for FFT forward in space, like in BEI)
** Deciding whether programs should work with velocities or slownesses, and the standard axis order for a velocity model file. 
** Standard axis order for inputs to programs that do similar things, i.e. switching a migration program for another in a SCons rule should be as simple as just changing the name of the program, without having to scratch one's head to determine how should the data and velocity be set up. Create Python metaprograms that add transparently to the user dimensions of length 1 to 2-D datasets when needed by programs that deal with 3-D data.