Hi, Doesn't DRMAA already do this? Andre: I thought the aim of SAGA was to provide a programmatic API rather than a command line tools interface? regards Omer Steven Newhouse wrote:
It may make sense to define common tools for job:
Submit Status Terminate
I'm not sure what broader interest we would have to do generic SAGA commands.
Steven
-----Original Message----- From: Andre Merzky [mailto:andre@merzky.net] Sent: Wednesday, June 04, 2008 2:48 PM To: Steven Newhouse Cc: Andre Merzky; ogsa-wg@ogf.org; ogsa-hpcp-wg@ogf.org Subject: Re: [ogsa-wg] Grid Command Line interfaces
Quoting [Steven Newhouse] (Jun 04 2008):
is a SAGA command line binding something you would conider worth pursuing? We actually started to do something like that, in a pet project...
Do you mean the ability to implement any defined command line interface using the SAGA APIs? (i.e. internal to the command) Or To define a set of command line tools to cover elements of the SAGA API?
The latter. For example, for the SAGA call
class saga::filesystem::file { void copy (saga::url src, saga::url tgt, it flags); }
define the command line tool
saga_file_copy [flags] <src> <tgt>
flags: session related flags -s|--session <s> run command in session s -c|--context <c> use context c
operational flags -a|--async=<Sync|Async|Task> use async mode Sync, Async or Task default is Sync call specific flags -r|--recursive copy recursively -o|--overwrite overwrite target if exists ...
So, the command line tools would basically reflect what we define in the SAGA API spec, with a set of flags which are consistent for all command line tools such defined.
A session could look like:
# saga_create_context --name=my_context --type=UserPass --user=anon <prompts for password>
# saga_create_session --name my_session --add_context=my_context
# /bin/date | saga_file_cat --session=my_session --write gsiftp://localhost/tmp/in.dat
# saga_file_copy --session=my_session gsiftp://localhost/tmp/in.dat gsiftp://remotehost/tmp/out.dat
# saga_file_cat --session=my_session gsiftp://remotehost/tmp/out.dat Wed Jun 4 14:43:27 CEST 2008
or, with some default assumptions of course (default session and context):
# /bin/date | saga_file_cat --write gsiftp://localhost/tmp/in.dat # saga_file_copy gsiftp://localhost/tmp/in.dat gsiftp://remotehost/tmp/out.dat # saga_file_cat gsiftp://remotehost/tmp/out.dat Wed Jun 4 14:43:27 CEST 2008
Best, Andre.
PS.: As for option (a) of yours: yes, that would be trivial to implement in SAGA :-) Well, at least it would be easy (one needs to add some magick for state management, to keep track of async ops and security credentials between separate calls to different tools.
Steven
-- Nothing is ever easy.
-- ogsa-wg mailing list ogsa-wg@ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg
-- http://www.cs.cf.ac.uk/User/O.F.Rana/index.html / work-fax:+44(0)29-2087-4598 work:+44(0)29-2087-5542 / other:+44(0)7956-299981 / distributed collaborative computing / room n2.14 / school of computer science / cardiff university queen's buildings / newport road / cardiff cf24 3aa / wales / uk