December 2007 - saga-rg - lists.ogf.org

HO. HO. HO.
by Andre Merzky 31 Dec '07

31 Dec '07

Hi folx, its unbelievable, but the SAGA saga seems to come to an end, finally: version one of the Core API specification has been submitted back to the OGF editor, and should await publication now. I hope this sweetens your look-back to 2007 which you will, w/o any doubt, enjoy today. (Well, for SAGA you could also look back to 2006, 2005, and some more... ;-) So, big thanks to all contributors, editors, criticists, and supportes of the spec! Please note that comments and error reports are continued to be wolcome, but will result in erratas to the spec, instead of direct fixes. Also, please note that the phrase 'final bug' is from now on forbidden on this list - there is no such thing! ;-) The final spec is linked at the bottom of the SAGA-RG wiki at SF: http://forge.ogf.org/sf/projects/saga-rg direct link: http://forge.ogf.org/short/saga-core-wg/saga-core-v1 Best wishes, and Seasons Greetings, Andre. PS.: of course you know 'Hogfather' from Terry Prattchet, don't you? HO. HO. HO. -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.

1 0

SAGA-related sessions att OGF22
by Thilo Kielmann 21 Dec '07

21 Dec '07

All, as today is the deadline for requesting session slots at the upcoming OGF22, I took the freedom to request the following for SAGA: 1. "Spec Adoption" track, 90 minutes workshop slot for SAGA and its adopters (e.g., OMII-UK, DEISA, NAREGI) Suggestions who should be invited to present in this session ??? 2. working group slot (90 minutes) Java language binding 3. working group slot (90 minutes) extension packages - service discovery - message bus - which other packages do we need? Anything that I have overlooked and should be added? Regards, Thilo -- Thilo Kielmann http://www.cs.vu.nl/~kielmann/

2 1

Re: [SAGA-RG] spec
by Andre Merzky 16 Dec '07

16 Dec '07

Quoting [Thilo Kielmann] (Dec 12 2007): > > On Tue, Dec 11, 2007 at 11:37:16PM +0100, Andre Merzky wrote: > > From: Andre Merzky <andre(a)merzky.net> > > To: Shantenu Jha <sjha(a)cct.lsu.edu>, Thilo Kielmann <kielmann(a)cs.vu.nl> > > Subject: spec > > > > [...] > > > > So, I'll go ahead and submit the spec tomorrow, ok? :-) > > > Veto!!! > > The spec is NOT OK as the wildcard thing is not resolved. > > What's the solution??? > > > Thilo Ah, right, that one... That indeed needs resolving. I post this answer to the list again then. I guess its 'your' way (B), as there were two votes (Ceriel, Thilo) against one (me). Hartmut voted as well for your suggestion, but on a choice which did not include 'my' version (C). So, either we just go with B (which I don't like too much, but hey... ;-), or do another straw poll, which is boring. Not a win-win-situation IMHO :-P Ok, Proposal: I summarize the options and their pro and cons below, and you and all list members you has a chance to do the right thing and vote 'C' until tomorrow evening. If nothing happens, 'B' is the one we will use. Options: (B) Add versions of the methods copy, link, move, and remove from ns_directory that accept a string parameter describing a pathname, relative to the CWD, (possibly) containing POSIX-style shell wildcards Correction 1: also for permission_allow/permission_deny Correction 2: remove the limitation to relative paths (C) Allow '*' as wildcard in URLs (in the path element part). Add an expand method for more elaborate wildcard expansion, which accepts a string and returns a list of URLs. Looping is in user space. In both cases, wildcards for attribs, find etc (which all are string patterns) are unaffected. In both cases, wildcards should only be allowed in the path element elements of the URLs (i.e. not in the scheme, host, port, auth or query elements of the URL). I am not sure if we came to a closure on 'Correction 2', but I think that Ceriels answer ("if you need abs paths, then do a 'cd()' to somewhere where you can use rel paths") is a rather inelegant workaround for a limitation which is not too well motivated, IMHO. So, please raise your voice now or hold your peace for evermore! Cheers, Andre. PS.: sorry for this biased mail ;-) -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.

3 16

Fwd (andre@merzky.net): Re: More confusion
by Andre Merzky 04 Dec '07

04 Dec '07

Hi all, Cerial came upon an ugly problem with the current spec: the wildcards used in the namespace package collide with the introduction of URLs, as several characters used for wildcards lead to not-well formed URLs. That problem was not present back then when we used strings instead of the saga::url class. Below is an email exchange describing the problem with examples. Opinions on how to solve that _nicely_ are very welcome. Thanks, Andre. ----- Forwarded message from Andre Merzky <andre(a)merzky.net> ----- > Quoting [Ceriel Jacobs] (Nov 20 2007): > > > > Ceriel Jacobs wrote: > > > >> Ceriel Jacobs wrote: > >> > >>> Hi, > >>> > >>> I am now looking at wildcard expansion, and am totally > >>> confused as to where/when that should take place. The > >>> ns_directory methods copy(), move(), link() and remove() > >>> seem reasonable targets, but they all take an URL > >>> parameter. This is sort of OK with the '*' wildcard, > >>> but using any of ?, [, ], {, } results in an invalid > >>> URL. For instance, > >>> ftp://ftp.cs.vu.nl/pub/ceriel/LLgen.?ar.gz is not a > >>> valid URL. > > Ah! Well, the wildcard spec still assumes that the > parameters are strings, not URLs :-( > > > >> Ahum, this IS a valid URL, with a query part. Anyway, not > >> what is intended. > > Right. > > > > OK, it can be done with %-escapes: I now get a match for > > > > ftp://ftp.cs.vu.nl/pub/ceriel/LLgen.%7Btar%2Cnoot%7D.gz > > Yes, I guess that works, but that leaves the effort to write > escaped charactes to the end user -- probably not what we > want. > > So, the problem really is to distinguish between characters > which the user added to describe wildcards, and characters > the user added to describe legitimate URL parts. Thats > impossible I'm afraid :-( > > Ugh. > > Justing dumping random thoughts from here: > > One option would be to forbid query parts etc on URLs. But > that would be a severe limitation. > > Another option would be to 'mark' wildcard characters, e.g. > to escape them with '\': > > ftp://ftp.cs.vu.nl/pub/ceriel/LLgen.\?ar.gz > > and to transform it internally into a/multiple valid URL(s). > That would imply that the saga::url class would need to be > aware of the escaping (so you cannot use a native URL > class), and the user still has to do some work. > > Another option is to revert to strings. Which removes your > parsing error, but does not solve the problem semantically - > at some point, the string needs to be converted into URLs. > > And yet another option is not to use wirldcards in the spec > - which is not really an option at this stage I guess, and > would be a pity as well. > > > ----- > > So, I do not have a good answer at the moment, and will > ponder some more on this. Do you mind if I forward the > question to Hartmut/Ole and to the list? > > Cheers, Andre. -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.

4 16