[ogsa-wg] Grid Command Line interfaces

[Omer F. Rana]

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 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.
>>     
> --
>   ogsa-wg mailing list
>   ogsa-wg at 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