[Swift-devel] Re: Analysis of wrapper.sh

[Ben Clifford]

in a similar context, plenty of people involved in swift development have 
had thoughts about how data management might change in the future.

it would be useful to define what the application 'contract' is, so as to 
separate out the accidental features of the wrapper as distinct from that 
contract.

So (in my mind, though others perhaps see it differently): an applciation 
can expect to be started up in a working directory that is not shared with 
any other applicaiton start up; and that mapped input files will be 
available for read only access within that directory (at top level or in 
subdirs, depending on mapping); and mapped output files should be left in 
that directory (at top level or in subdirs, depending on mapping)

Applications should not make assumptions about the nature of the file 
system (which is how the wrapper can have an option to switch between 
working dirs on the worker node or on shared fs). Nor should they 
necessarily assume that the wrapper.sh script is the way in which things 
get there, or that there is a shared directory at all; for example, if 
Falkon's real or future data management features were wired in, Falkon 
might handle the movement of files from some submit-side location to 
individual application working directories...

Separate from the above is our implementation of that interface, which is 
both the wrapper.sh on the worker side and behaviour in the submit-side 
Swift code to manage the site-side shared directories.

--