Participants
- Moreno (M)
- Oxana (O)
- Etienne (E)
- Andrew (A)
- Morris (Mo) - notes on behalf of Johannes (vacation)
- Balazs (B)
- Steven (St)
- osakamatsuda (OM)
- tsurusawa (T)
- aleksandr (AS)
- Mark Morgan (MM)



### GES and BES history
- A: Requirement document instead of strawman
- A: Different discussions etc.
- A: Many things cut out of BES over time (old versions)
- A: Look at older documents
- M: Useful to look at old documents
- A: 26 & 32 versions most interesting
- A: Pending, staging-in, etc. states similiar - "deja-vu"
- Mo: Major difference between BES at this time w/o no 

implementation/experience 
- Mo: Now we have production experience and implementation 

experience
- MM: time to look beyond basics - cut of in history often because 

of 'basic' scope
- B: Please indicate the points in the older BES versions that 

matter for PGI GES

# A - TODO: Point to interesting sections in older BES 

documents/discussions w same issues
 


### GES formating problems
- E: Formating problems
- B: We fix formating ASAP
- St: Use MS




### GES Document - Data-staging
- M: Same document - but in PDF format - after call revised in 

structure/formating
- M: Data-staging discussion today



### First scenario: Data-staging "client push"
- B: Client pushing data into the GES
- B: Not covered by BES currently
- B: We need the location where to put "manually" data from the 

client --> data push
- Mo: experience in BES with this issue -> Andrew?
- A: BESActivity portType: URI with Data, primary model was pull
- A: Some discussions to cut out data staging completely, but push 

was to complicated
- MM: Take care about the states (i.e. pending) during data-push 

scenarios 
- M: Allow start-up of activity later
- O: Intermediate result checkings are necessary...
- E: WMS or user will perform pushing? If WMS then possible, if 

user then obstacles probably
- E: user means client?! that might be also the WMS


# A - TODO: Write some notes about data push discussions






### Second scenario: GES pulling input data
- B: broadly supported
- B: The GES needs some credentials for delegation in this sense
- MM: Work in the OGSA groups for credential delegations...





### Third scenario: GES pushing out data
- Mo: ...lost because of bad formating
- B: watch out of difficult formating... :-)




### Fourth scenario: stagein/out: performed as part of the grid job 

execution
- B: how the clients get the url for the output directory...
- B: session directory would be useful for here as well
- B: When the client is pulling out of the location - special 

source
- O: Is it really always the same directory?


### DISCLAIMER
- Mo: the scenarios not necessarily map with the different document 

versions


### All scenarios
- M: Updated a new document where data-staging is more clear now
- B: which ones should be mandatory which ones should be optional
- M: A service advertise this information
- Mo: We need precise names/terms for the different stagings then 

(i.e. sub-profiles?!)
- E: considered only data is locally at computing sites 
- B: what do you mean
- E: Storage resource, which is quite close to the computing 

resource
- O: Why should this be managed by computing service?
- E: Very good connectivity with a computing resource
- E: We should not assume that the data is always in the session 

directory (but close elsewhere)
- O: local disk or not doesn't matter
- E: Staging-out directory might be different from session 

directory...
- E: before submission a client ensures that a replica is close to 

the destination
- O: Scheduling the job close to the data - scheduling problem
- Mo: scope of data-staging is cores/cpu work on accessible data, 

putting the job close to the data is out of scope and is already 

intelligent data-staging/scheduling/brokering issues
- E: Write...