Hi group, we plan to have the following sessions at GGF-15 - please let us know if you have comments: Session 1: SAGA Use Case Mappings The session will present the SAGA API Draft, and publicly discuss the mapping of the API to the SAGA Use Cases. - Administrativa, GGF agenda bashing (10 min) - presentation of SAGA API (20 min) - mapping 3 Use Cases to API (60 min) Session 2: SAGA API Discussion The session will host a low level discussion of the current SAGA API draft. The draft is supposed to advance to submission status soon. The session will also host a discussion of higher level issues, such as the handling of future API extensions, and language bindings. - agenda bashing ( 5 min) - API discussion (60 min) - General discussion (25 min) Session 3: SAGA Requirement Doc Discussion The group will work on the current draft of the Requirement Document. - agenda bashing ( 5 min) - document discussion (85 min) Cheers, Andre. -- +-----------------------------------------------------------------+ | 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 | | +-----------------------------------------------------------------+
Dear all, First of all apologies if this is something that you have discussed already or if it is regarded as implementation specific or is even naive. Here at EPCC we are primarily implementing those methods for handling entities in the NSDir interface. In doing so we have come up with the following comments and questions. It would be fantastic if some of you could respond to these to help clear up matters for us. Thanks for any help with this. Best regards, Terry Sloan 1. Are both source and target relative to a current working directory ? 2. Can the absolute path be used in the source and target ? 3. Can source be remote (ie. not local) ? 4. If the source and target working directories are persistent for a user session where are they to be stored? 5. If both absolute and relative paths can be used how are these to be distinguished? 6. In the very first call to a SAGA API, if the source or target is relative to a current working directory then where is the source or target current working directory set ? Particularly if the source is non-local. -- ---------------------------------------------------------------------- Terry Sloan Email: t.sloan@epcc.ed.ac.uk EPCC Phone: +44 131 650 5155 WWW : http://www.epcc.ed.ac.uk/ ----------------------------------------------------------------------
Hi Terry! Quoting [Terry Sloan] (Aug 26 2005):
Terry Sloan
1. Are both source and target relative to a current working directory ?
Yes. I made that clearer in the spec.
2. Can the absolute path be used in the source and target ?
Yes.
3. Can source be remote (ie. not local) ?
Yes. All file names, dir names etc. are supposed to be URI's, and are allowed to be local or remote, absolute or relative.
4. If the source and target working directories are persistent for a user session where are they to be stored?
That is up to the implementation - the API does not imply any persistency right now, so any implementation not providing persistency between sessions can still be SAGA compliant. I am actually not sure if the API is allowing persistency for many things. PWD should be no problem, the same for the default session and context.
5. If both absolute and relative paths can be used how are these to be distinguished?
Long asnwer: This is a difficult question, as we had many (and I expect we will have many more) discussions about URI's, and how to express absolute and relative paths. For simple file names it is, well, simple: - absolute file names start with '/' - relative file names don't start with '/' For URI's is tricky. Several parties expressed the opinion, that it is impossible to specify relative paths with URI's. Consider http://www.host.net:1234/tmp/data.txt The 3rd '/', which separates host/port from the path element, is often considered part of the path. That would result in '/tmp/data.txt', and is absolute. Other people say, that the 3rd slash is not part of the path, and the above uri points to 'tmp/data.txt', which is relative. In their opinion, an absolute URI would need two slashes, like: http://www.host.net:1234//tmp/data.txt I am personally not sure which way is 'correct'. I think acceptable are both. Now, it is probably not part of the SAGA groups agenda to semantically define URI's. Hence we could just throw up hands and cry "implementation dependend". However, it would be good to include a proposal for URI handling into the spec. Its not in there yet. Short answer: *shrug*
6. In the very first call to a SAGA API, if the source or target is relative to a current working directory then where is the source or target current working directory set ? Particularly if the source is non-local.
Short answer: *shrug* ;-) Long answer: it depends... For example, if you are using http as protocol for the rmote URI, your 'pwd', which would be the default directory on the remote host, would be http-root, e.g. /var/www/htdocs/. For an ftp uri, it might be /usr/ftp/pub/, for ssh it might be your home directory. Or a sandbox. We are not happy about that mess. In particular, it makes it difficult to translate an uri with scheme A into an uri with scheme B - unless you know the local setting for that scheme on that host, for the respective user. Ugh! The same remark as above holds I think: SAGA cannot solve that problem, really, but it would be nice to have a sensible, simple and acceptable description/recommendation for that in the spec - right now we don't. I hope that helps. Thanks for the remarks, Andre. -- +-----------------------------------------------------------------+ | 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 | | +-----------------------------------------------------------------+
On Fri, 26 Aug 2005, Andre Merzky wrote:
6. In the very first call to a SAGA API, if the source or target is relative to a current working directory then where is the source or target current working directory set ? Particularly if the source is non-local.
Short answer: *shrug* ;-)
Long answer: it depends...
I was assuming the current working directory for an NSDir (well, a physical directory or a logical directory) would be set in its constructor, although looking at the spec I see that this is missing. Let me make it a proposal then 8-) Tom
Hmm, maybe I misunderstood the question. Opening (or constructing) a dir should have a uri as parameter, which is the initial pwd. (BTW: adding the constructors is on my TODO list I think - thanks for the remonder ;-) But what is about this case: dir d ("http://www.host.net/home/andre"); d.copy ("http://www.host.net/home/andre/test.dat", "./test.dat"); What is the target of the copy call relative to? As terry said, even more difficult for the relative remote case. Cheers, Andre. Quoting [Tom Goodale] (Aug 26 2005):
On Fri, 26 Aug 2005, Andre Merzky wrote:
6. In the very first call to a SAGA API, if the source or target is relative to a current working directory then where is the source or target current working directory set ? Particularly if the source is non-local.
Short answer: *shrug* ;-)
Long answer: it depends...
I was assuming the current working directory for an NSDir (well, a physical directory or a logical directory) would be set in its constructor, although looking at the spec I see that this is missing. Let me make it a proposal then 8-)
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 | | +-----------------------------------------------------------------+
On Fri, 26 Aug 2005, Andre Merzky wrote:
Hmm, maybe I misunderstood the question. Opening (or constructing) a dir should have a uri as parameter, which is the initial pwd. (BTW: adding the constructors is on my TODO list I think - thanks for the remonder ;-)
But what is about this case:
dir d ("http://www.host.net/home/andre");
d.copy ("http://www.host.net/home/andre/test.dat", "./test.dat");
What is the target of the copy call relative to? As terry said, even more difficult for the relative remote case.
It should be relative to the pwd of d, in the same way as when I do cd /home/andre cp /home/andre/test.dat ./test.dat (which would of course give an error as they are the same file); target is relative to the current working directory. Tom
Cheers, Andre.
Quoting [Tom Goodale] (Aug 26 2005):
On Fri, 26 Aug 2005, Andre Merzky wrote:
6. In the very first call to a SAGA API, if the source or target is relative to a current working directory then where is the source or target current working directory set ? Particularly if the source is non-local.
Short answer: *shrug* ;-)
Long answer: it depends...
I was assuming the current working directory for an NSDir (well, a physical directory or a logical directory) would be set in its constructor, although looking at the spec I see that this is missing. Let me make it a proposal then 8-)
Tom
Hmm, ja, you are right I guess. Otherwise we would speak about multiple pwd's, which does not make sense. A. Quoting [Tom Goodale] (Aug 26 2005):
On Fri, 26 Aug 2005, Andre Merzky wrote:
Hmm, maybe I misunderstood the question. Opening (or constructing) a dir should have a uri as parameter, which is the initial pwd. (BTW: adding the constructors is on my TODO list I think - thanks for the remonder ;-)
But what is about this case:
dir d ("http://www.host.net/home/andre");
d.copy ("http://www.host.net/home/andre/test.dat", "./test.dat");
What is the target of the copy call relative to? As terry said, even more difficult for the relative remote case.
It should be relative to the pwd of d, in the same way as when I do
cd /home/andre
cp /home/andre/test.dat ./test.dat
(which would of course give an error as they are the same file); target is relative to the current working directory.
Tom
Cheers, Andre.
Quoting [Tom Goodale] (Aug 26 2005):
On Fri, 26 Aug 2005, Andre Merzky wrote:
6. In the very first call to a SAGA API, if the source or target is relative to a current working directory then where is the source or target current working directory set ? Particularly if the source is non-local.
Short answer: *shrug* ;-)
Long answer: it depends...
I was assuming the current working directory for an NSDir (well, a physical directory or a logical directory) would be set in its constructor, although looking at the spec I see that this is missing. Let me make it a proposal then 8-)
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 | | +-----------------------------------------------------------------+
On Fri, 26 Aug 2005, Tom Goodale wrote:
On Fri, 26 Aug 2005, Andre Merzky wrote:
Hmm, maybe I misunderstood the question. Opening (or constructing) a dir should have a uri as parameter, which is the initial pwd. (BTW: adding the constructors is on my TODO list I think - thanks for the remonder ;-)
But what is about this case:
dir d ("http://www.host.net/home/andre");
d.copy ("http://www.host.net/home/andre/test.dat", "./test.dat");
What is the target of the copy call relative to? As terry said, even more difficult for the relative remote case.
It should be relative to the pwd of d, in the same way as when I do
cd /home/andre
cp /home/andre/test.dat ./test.dat
(which would of course give an error as they are the same file); target is relative to the current working directory.
Of course that then begs the question of how to copy a local file to a remote file or a remote file to a local file easily. I guess one way would be to use a file:// URI for that. However if we have a directory object, it should have the same semantics as the current working directory for a process. Tom
participants (3)
-
Andre Merzky -
Terry Sloan -
Tom Goodale