[ogsa-wg] [DRMAA-WG] Grid Command Line interfaces

[Daniel Templeton]

DRMAA is narrowly focused on offering an API, but as was already pointed 
out, as soon as you have a Perl binding (which we do), the API itself 
also becomes a set of commands.

Daniel

Andre Merzky wrote:
> Well, DRMAA is an API specification as well, so does not
> really define command line tools in the spec.  There are a
> number of tools available, but I am not qualified to say if
> the DRMAA group intended to have a complete API mapping, or
> plan to standardize these tools, etc.
>
> Cc to the DRMAA group, maybe they have input on the topic...
>
> Quoting [Omer F. Rana] (Jun 04 2008):
>   
>> Date: Wed, 04 Jun 2008 16:35:13 +0100
>> From: "Omer F. Rana" <o.f.rana at cs.cardiff.ac.uk>
>> To: Andre Merzky <andre at merzky.net>
>> Subject: Re: [ogsa-wg] Grid Command Line interfaces
>>
>> Hi Andre,
>>
>> Thanks. It might be useful to understand the relationship between these 
>> and commands provided
>> in DRMAA perhaps? Just a thought.
>>
>> best wishes
>> Omer
>>
>> Andre Merzky wrote:
>>     
>>> Hi Omer
>>>
>>> Quoting [Omer F. Rana] (Jun 04 2008):
>>>  
>>>       
>>>> 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?
>>>>    
>>>>         
>>> Of course, you are perfectly right.  However, several people
>>> (including our won group) use SAGA for the purpose to write
>>> such command line tools (which are then middleware
>>> independent), and thus we considered mappings from the SAGA
>>> API to command line tools since quite a while...
>>>
>>> Best, Andre.
>>>
>>>  
>>>       
>>>> 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
>>>>>