[ogsa-wg] Grid Command Line interfaces

[Steven Newhouse]

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 at merzky.net]
> Sent: Wednesday, June 04, 2008 2:48 PM
> To: Steven Newhouse
> Cc: Andre Merzky; ogsa-wg at ogf.org; ogsa-hpcp-wg at 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.