[saga-rg] Notes from meeting with BES and Byte-IO

[Andre Merzky]

Hi Tom, all, 

[ insert usual excuse about late answer here... ] ;-)


Quoting [Tom Goodale] (Dec 12 2005):
> 
> Hi,
> 
> I had just had a meeting with the BES and Byte-IO people to check that we 
> are all vaguely in sync.  The overall reception was postive, and there 
> were a comments which came up when we were ging through things:
> 
> Namespaces:
> 
> getURL -> getCWD
> 
>   - as we are already talking about namespaces, and have the concept of a
>     directory, URL was seen to be inappropriate here.  I've just thought
>     why didn't we just name it getPath ?

getCWD would not work, as for a file it returns the complete
name of the file, not the directory it lives in.  So getPath
would be more appropriate.  OTOH, we have that call on
streams as well, where it gives you the, well, URL to
contact the respective stream server.  getPath would not fit
there, not would getCWD.  So, getURL seems to be the more
generic version.

Of course, we could make it different for name spaces and
streams.  But is URL (or maybe better URI) really not
appropriate?

> Links aren't generic
>   - could we move those off the generic namespace interface ?

Right, they are not, but that does not hurt in this case I
think.  Links are not generic on my linux box either (no
hard links between drives), but still the command is there -
it jsut gives an error if linking is not possible for
specific drives etc.

For that matter, mkdir is not generic either ;-)

Well, somewhat weak argument, I know.  A better one might
be:

Right now, the namespace API describes how to handle
entities in the name space, and the file and logical-file
APIs describe how to access these entities.  That is a very
clean and nice distinction.  If we move links away from name
space, we loose that distinction.  Should we then also move
mkdir (http has no mkdir)?  Or move (ftp has no move)?


> RNS-Lite has a unified namespace.  (I guess this is similar to the GAT 
> advert-service type namespace where any object could be stored.)  The 
> suggestion was that SAGA should have one, and then there would be a 
> namespace method which got the opaque token (EPR for RNS-Lite) which could 
> be passed into the constructor of a file, etc; with isX methods to tell 
> what sort of object was being pointed to by the opaque token.
> 
>   - this has obvious advantages in having just one namespace about, but
>     does break the complete seperation of underlying implementation that
>     we have currently, plus also requiring at least one call to
>     instantiate an object, as currently have open methods which act as the
>     appropriate factory methods to return files, logical files, etc.

Thats an interesting point.  I would like that =- what do
others think?

I think it can be implemented on top of the current model,
by changing the name space from interface to class.  We
should be careful with that tnhough, as we have then the
single inheritance valence of file and logical file filled
by name space.  OTOH, it seems unwise to not implement name
space for the file class directly, as one would then require
to go the additional call for instanciation - but most use
cases seem quite specifically targeting non-unified name
spaces.


> Files:
> 
> writeP and readP are not described in the document.  Are they really 
> distinct from the writeV and readV or just a subset of the functionality ?

They are a superset.  The pattern in question are describing
a nested list of regular access patterns.  I will add the
description to the spec, thanks.


> Jobs:
> 
> Three more possible states were suggested
> 
> Staging In
> Staging Out

we have PreExecution and PostExecution, which are, I think,
supposed to cover these stages.  

Digging around in the email list archive, I found from a
discussion between Chris and me:

[Christopher Smith <csmith at platform.com>]
  Also, there is a more complicated state model for
  "activities" emerging from the OGSA-BES work, that also
  includes sub-states for file staging, etc, etc.  We can
  perhaps incorporate some of that as well, although I'm
  happy with general Pre-execution and Post-execution states
  to cover all of this.


> Exception starting job (BES has this)

what is the difference to a failed job (DoneFail)?  I guess
we should discuss the job state diagram at GGF again, as
there are some related open issues in our TODO list (see
next mail).


> Contexts/sessions:
> 
> There was a suggestion that perhaps OGSA needs to pass generic context 
> data about, sparked by the observation that SAGA and other systems do have 
> the concept of a 'context';  would it make sense for SAGA for us to have 
> sessions (or maybe all objects) provide the attribute interface and 
> allow users to associate arbitrary key value pairs with it ?

I think we (or OGSA) should come up with a real use case.

Hmm, right now it looks like saga has session because it
might be useful for interacting with middleware, and OGSA as
middleware think about sessions because APIs as SAGA have
them ;-)

AFAICS, sessions in SAGA are mainly for the purpose of
separating interactions to different middleware systems.
E.g. you might want to have one session which talks to a ssh
enabled resource (so has an ssh context attached), and
another session which talks to a globus gatekeeper (so has a
x509 context attached).

Session in SAGA implies nothing about server side state so
far.

Cheers, Andre.


> Cheers,
> 
> Tom



-- 
+-----------------------------------------------------------------+
| Andre Merzky                      | phon: +31 - 20 - 598 - 7759 |
| Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 |
| Dept. of Computer Science         | mail: merzky at cs.vu.nl       |
| De Boelelaan 1083a                | www:  http://www.merzky.net |
| 1081 HV Amsterdam, Netherlands    |                             |
+-----------------------------------------------------------------+