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@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@cs.vu.nl | | De Boelelaan 1083a | www: http://www.merzky.net | | 1081 HV Amsterdam, Netherlands | | +-----------------------------------------------------------------+