[graap-wg] Telecon on 3/21

[Karl Czajkowski]

On Mar 21, Jon MacLaren loaded a tape reading:
> Hi Karl,
> 
> Ok, I wasn't at the face-to-face meetings - I should have read the 
> minutes.  But then I was out of the loop for a while during those 
> times.  But where would someone new to the group pick up this 
> information?  It is likely that a new user would read the group 
> charter, the use cases, and then the example in the specification.  
> Lets look at each of these in turn.
> 

We're in agreement.  That's why I said people do not understand how to
use WS-Agreement and GRAAP-WG needs to do a better job of
communicating its design goals and expected usage scenarios. :-)


> Why don't you put together a simple informational document that shows 
> the process of a user creating a job using WS-Agreement, the staging in 
> of files, the execution, and staging out of results.  Something that 
> shows all the interactions between the user, the agreement provider, 
> the resource manager, etc.  The authors of the spec obviously have very 
> clear intentions about this - they should be clearly stated somewhere!
> 

I think there was a momentary identity crisis in GRAAP-WG back about
1.5 years ago, when the generalization thought process was in full
swing and some folks started reacting negatively to domain-specific
instantiations as "out of scope."  I hope we have that out of our
systems now...


> I think that such a document would be very valuable at this point.  It 
> could also be a valuable input to the BES group, to show you their 
> intent - I didn't pick up on your viewpoint from your presentation in 
> Seoul, and I think I was pretty awake at that point (you were lucky 
> :-).
> 

Really??  I feel like I am in the Twilight Zone...

I thought I said explicitly that WS-Agreement is a generalization of
the GRAM pattern for "creating a job" and could use JSDL instead of
our GRAM job language. I then added that this had to be weighed
against their milestones to decide whether to do it or take a more
traditional approach, and gave due warning about the difficulty of
rendering either type of interface on a short schedule, i.e. the devil
is in the details, and the traditional approach is not necessarily the
conservative approach since it can lead to repetition of mistakes.


> The group might also want to consider updating the charter.
> 
> Jon.
> 

karl

-- 
Karl Czajkowski
karlcz at univa.com