[saga-rg] GGF16 SAGA session 3 Notes

[Shantenu Jha]

GGF16 (Athens), Wed 15 Feb, SAGA Session #3, 10:30-12:00 

http://wiki.cct.lsu.edu/saga/space/GGF16+Meeting+Notes

Summary:

Session devoted to discussing main aspects of the Requirement Document
(in progress, close to delivery) as well as address the "next Top 10"
on the issue list.

Discussed the the structure of the evolving Requirement document ,
highlights of the document and issue list.

Some feedback on the Requirement Document:

- "Efficient data access... supported by the SAGA API"
  
  Need to say what is being said better
  Also add more text to the description..

 " Data Access should be supported by the SAGA API which in a way 
  does not preclude efficient access"

- "Data Replication"
   Clarify.
  
- "Information Services" 

  Suprised (yet again!) by the number of Use Cases requesting IS
  This needs to be investigated further by Andre+Shantenu

-  "Streams"
   OK

- "Events and Steering"
  OK

Non-Functional Areas.
====================

-  Transactions are difficult to do...

- Gridlab: Pg 15

- Clarify in text remarks about whether it is for
  Middleware technology or middleware implementation.
	

  ** Deiter K offered to be persuaded to extract more Use Cases from
  ** EGEE/gLite. Jha to follow up**

Other General comments on the Requirements Doc:
=============================================

- Conclusions section requires work


- Steven Newhouse: What are the next steps?
  Should be ready for submission/feedback in the
  next two weeks.

- Suggestion for the 'doc snapshot' to be placed on the Wiki

[ Probably not until the stable version is ready; till then
please rely on CVS] 

=============================	 =============================	 

Second half of SAGA session#3 

Most responses/discussions have been entered into the
Issue list, which can be found from the SAGA CVS respository.

Issue list:
=========
 - issue 26
    URL problem: any solution? 
    allow any, 'any://'? 

    Do we have an "upward compatibility" path with GFS?
    
    AM: We think we are fine..

    SN: "Seems Dangerous to Expect that level of intelligence
         at the API Level".

	  Needs further discussion
	  Complexity vs completeness?

 - issue 26)
   why not on shell wildcards?
       
       windows does support "*" -- not as powerful as linux

       will there be wildcard specification in GFS?
       therefore defer to GFS solution

 - issue 50)

    Discussion from BES:         Two stage cancel.	  
	       
    AM: proposed a sub-state model

 -  Issue 64/68
    
    Agreement on the fact that it should be allowed to return immediately.

 -  Issue 120)
    
    Accept Hartmut's solution! [see issue list]

 - Issue 110)
   
    Attach object's session to the error constructor..

 - Issue 108)
	 
    Some global error state...
	 will help auditing etc.,

   "is supported" as an attribute..