Hi group(s), the deed is done, finally, and we incorporated all public comments back into the SAGA spec, and then some. And then some more. So, we would like to have a one week final call within the SAGA groups before we resubmit to the OGF editor. So, please, have a look at the document(s), and raise your voice if there is something you don't agree with. There are no open known issues at the moment, no TODO's and no FIXME's. But the text needs reviewing from a native (or good) English speaker, and also needs some formatting fixes. Shantenu and Thilo agreed to help with that, but more volonteers are VERY welcome! I attach two versions of the document: the clean version which is to be resubmitted, and a version which includes markup of the changes. The markup semantics is: red : removed green : fixed blue : added For large parts of the text (the verbatim sections), you'll find diff style markups + : added ! : fixed - : removed I'll try to come up with a detailed change log tomorrow or Friday, which should help you to understand the evolution of the document. BTW, the spec grew bigger again, but mostly because of added details, and not of added semantics. Cheers, Andre PS.: we know of course that a one week final call is short, but we would _really_ like to get the spec out of the door by OGF21. If you have concerns about the short call, please let us know! -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
Hi Andre, now that the URL specs are in the repository, I have a question about it: why are there separate methods for "username" and "password"? rfc2396 mostly talks about a "userinfo" token, with the user:password possibility made scheme-specific. In fact, the rfc2396 text warns against having passwords in there, because of the security risk. So, I would prefer set_userinfo/get_userinfo methods instead of the get_[username|password]/set_[username|password]. Ceriel
Ceriel Jacobs wrote:
Hi Andre,
now that the URL specs are in the repository, I have a question about it: why are there separate methods for "username" and "password"? rfc2396 mostly talks about a "userinfo" token, with the user:password possibility made scheme-specific. In fact, the rfc2396 text warns against having passwords in there, because of the security risk. So, I would prefer set_userinfo/get_userinfo methods instead of the get_[username|password]/set_[username|password].
Oops, I was looking at an obsolete RFC, but rfc3986 basically sais the same. Ceriel
Good point, and my mistake. I changes that in the spec. Thanks, Andre. Quoting [Ceriel Jacobs] (Oct 08 2007):
Hi Andre,
now that the URL specs are in the repository, I have a question about it: why are there separate methods for "username" and "password"? rfc2396 mostly talks about a "userinfo" token, with the user:password possibility made scheme-specific. In fact, the rfc2396 text warns against having passwords in there, because of the security risk. So, I would prefer set_userinfo/get_userinfo methods instead of the get_[username|password]/set_[username|password].
Ceriel
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
Andre, Shouldn't the constructors of namespace, file, directory etc. take url's now (in stead of the string parameters)? This wouldn't even break existing code (at least in C++) as long as there is a non-explicit url constructor takig a string only. Regards Hartmut
-----Original Message----- From: saga-rg-bounces@ogf.org [mailto:saga-rg-bounces@ogf.org] On Behalf Of Andre Merzky Sent: Monday, October 08, 2007 3:17 PM To: Ceriel Jacobs Cc: SAGA RG; Andre Merzky Subject: Re: [SAGA-RG] saga core spec - final call
Good point, and my mistake. I changes that in the spec.
Thanks, Andre.
Quoting [Ceriel Jacobs] (Oct 08 2007):
Hi Andre,
now that the URL specs are in the repository, I have a
why are there separate methods for "username" and "password"? rfc2396 mostly talks about a "userinfo" token, with the user:password possibility made scheme-specific. In fact, the rfc2396 text warns against having passwords in there, because of the security risk. So, I would prefer set_userinfo/get_userinfo methods instead of
question about it: the get_[username|password]/set_[username|password].
Ceriel
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced. -- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg
Yes, they should - thats the idea after all. I'll fix that. Thanks, Andre. Quoting [Hartmut Kaiser] (Oct 08 2007):
Andre,
Shouldn't the constructors of namespace, file, directory etc. take url's now (in stead of the string parameters)? This wouldn't even break existing code (at least in C++) as long as there is a non-explicit url constructor takig a string only.
Regards Hartmut
-----Original Message----- From: saga-rg-bounces@ogf.org [mailto:saga-rg-bounces@ogf.org] On Behalf Of Andre Merzky Sent: Monday, October 08, 2007 3:17 PM To: Ceriel Jacobs Cc: SAGA RG; Andre Merzky Subject: Re: [SAGA-RG] saga core spec - final call
Good point, and my mistake. I changes that in the spec.
Thanks, Andre.
Quoting [Ceriel Jacobs] (Oct 08 2007):
Hi Andre,
now that the URL specs are in the repository, I have a
why are there separate methods for "username" and "password"? rfc2396 mostly talks about a "userinfo" token, with the user:password possibility made scheme-specific. In fact, the rfc2396 text warns against having passwords in there, because of the security risk. So, I would prefer set_userinfo/get_userinfo methods instead of
question about it: the get_[username|password]/set_[username|password].
Ceriel
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced. -- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
Andre, There is just one small thing I don't like. In section 3.8 it says: "Non-optional attributes MUST have a default value (which can be an empty string)." We have found this rather inconvenient for the service discovery work where we often return values which are not optional but have no default value - for example the URL of a service. We have been obliged to give these default values of empty strings which is misleading - and is not even a valid URL (I think). Would it break anything if this sentence were to be deleted? I am sorry to bring this up at the last moment Steve
-----Original Message----- From: saga-rg-bounces@ogf.org [mailto:saga-rg-bounces@ogf.org] On Behalf Of Andre Merzky Sent: 03 October 2007 21:37 To: SAGA RG Cc: Gregory Newby; Shantenu Jha Subject: [SAGA-RG] saga core spec - final call
Hi group(s),
the deed is done, finally, and we incorporated all public comments back into the SAGA spec, and then some. And then some more.
So, we would like to have a one week final call within the SAGA groups before we resubmit to the OGF editor. So, please, have a look at the document(s), and raise your voice if there is something you don't agree with. There are no open known issues at the moment, no TODO's and no FIXME's. But the text needs reviewing from a native (or good) English speaker, and also needs some formatting fixes. Shantenu and Thilo agreed to help with that, but more volonteers are VERY welcome!
I attach two versions of the document: the clean version which is to be resubmitted, and a version which includes markup of the changes. The markup semantics is:
red : removed green : fixed blue : added
For large parts of the text (the verbatim sections), you'll find diff style markups
+ : added ! : fixed - : removed
I'll try to come up with a detailed change log tomorrow or Friday, which should help you to understand the evolution of the document.
BTW, the spec grew bigger again, but mostly because of added details, and not of added semantics.
Cheers, Andre
PS.: we know of course that a one week final call is short, but we would _really_ like to get the spec out of the door by OGF21. If you have concerns about the short call, please let us know!
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
I can't remember the reason for that statement for the life of me *blush* So, at the moment I'm perfectly fine with removing that requirement. Cheers, Andre. Quoting [Fisher, SM (Steve)] (Oct 10 2007):
Andre,
There is just one small thing I don't like. In section 3.8 it says: "Non-optional attributes MUST have a default value (which can be an empty string)."
We have found this rather inconvenient for the service discovery work where we often return values which are not optional but have no default value - for example the URL of a service. We have been obliged to give these default values of empty strings which is misleading - and is not even a valid URL (I think).
Would it break anything if this sentence were to be deleted?
I am sorry to bring this up at the last moment
Steve
-----Original Message----- From: saga-rg-bounces@ogf.org [mailto:saga-rg-bounces@ogf.org] On Behalf Of Andre Merzky Sent: 03 October 2007 21:37 To: SAGA RG Cc: Gregory Newby; Shantenu Jha Subject: [SAGA-RG] saga core spec - final call
Hi group(s),
the deed is done, finally, and we incorporated all public comments back into the SAGA spec, and then some. And then some more.
So, we would like to have a one week final call within the SAGA groups before we resubmit to the OGF editor. So, please, have a look at the document(s), and raise your voice if there is something you don't agree with. There are no open known issues at the moment, no TODO's and no FIXME's. But the text needs reviewing from a native (or good) English speaker, and also needs some formatting fixes. Shantenu and Thilo agreed to help with that, but more volonteers are VERY welcome!
I attach two versions of the document: the clean version which is to be resubmitted, and a version which includes markup of the changes. The markup semantics is:
red : removed green : fixed blue : added
For large parts of the text (the verbatim sections), you'll find diff style markups
+ : added ! : fixed - : removed
I'll try to come up with a detailed change log tomorrow or Friday, which should help you to understand the evolution of the document.
BTW, the spec grew bigger again, but mostly because of added details, and not of added semantics.
Cheers, Andre
PS.: we know of course that a one week final call is short, but we would _really_ like to get the spec out of the door by OGF21. If you have concerns about the short call, please let us know!
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
Andre, Having considered this a little more, I think that default values only make sense for non-optional attributes that are R/W. Default values are not useful for the other 3 combinations. Steve
-----Original Message----- From: Andre Merzky [mailto:andre@merzky.net] Sent: 10 October 2007 22:15 To: Fisher, SM (Steve) Cc: Andre Merzky; SAGA RG Subject: Re: [SAGA-RG] saga core spec - final call
I can't remember the reason for that statement for the life of me *blush* So, at the moment I'm perfectly fine with removing that requirement.
Cheers, Andre.
Quoting [Fisher, SM (Steve)] (Oct 10 2007):
Andre,
There is just one small thing I don't like. In section 3.8
it says:
"Non-optional attributes MUST have a default value (which can be an empty string)."
We have found this rather inconvenient for the service discovery work where we often return values which are not optional but have no default value - for example the URL of a service. We have been obliged to give these default values of empty strings which is misleading - and is not even a valid URL (I think).
Would it break anything if this sentence were to be deleted?
I am sorry to bring this up at the last moment
Steve
-----Original Message----- From: saga-rg-bounces@ogf.org [mailto:saga-rg-bounces@ogf.org] On Behalf Of Andre Merzky Sent: 03 October 2007 21:37 To: SAGA RG Cc: Gregory Newby; Shantenu Jha Subject: [SAGA-RG] saga core spec - final call
Hi group(s),
the deed is done, finally, and we incorporated all public comments back into the SAGA spec, and then some. And then some more.
So, we would like to have a one week final call within the SAGA groups before we resubmit to the OGF editor. So, please, have a look at the document(s), and raise your voice if there is something you don't agree with. There are no open known issues at the moment, no TODO's and no FIXME's. But the text needs reviewing from a native (or good) English speaker, and also needs some formatting fixes. Shantenu and Thilo agreed to help with that, but more volonteers are VERY welcome!
I attach two versions of the document: the clean version which is to be resubmitted, and a version which includes markup of the changes. The markup semantics is:
red : removed green : fixed blue : added
For large parts of the text (the verbatim sections), you'll find diff style markups
+ : added ! : fixed - : removed
I'll try to come up with a detailed change log tomorrow or Friday, which should help you to understand the evolution of the document.
BTW, the spec grew bigger again, but mostly because of added details, and not of added semantics.
Cheers, Andre
PS.: we know of course that a one week final call is short, but we would _really_ like to get the spec out of the door by OGF21. If you have concerns about the short call, please let us know!
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced. -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
Right. But then we don't need the statement you cited, as we already define default values for non-optional attributes. So I think we are better off with removing the statement altogether. Cheers, Andre. Quoting [Fisher, SM (Steve)] (Oct 11 2007):
Andre,
Having considered this a little more, I think that default values only make sense for non-optional attributes that are R/W. Default values are not useful for the other 3 combinations.
Steve
-----Original Message----- From: Andre Merzky [mailto:andre@merzky.net] Sent: 10 October 2007 22:15 To: Fisher, SM (Steve) Cc: Andre Merzky; SAGA RG Subject: Re: [SAGA-RG] saga core spec - final call
I can't remember the reason for that statement for the life of me *blush* So, at the moment I'm perfectly fine with removing that requirement.
Cheers, Andre.
Quoting [Fisher, SM (Steve)] (Oct 10 2007):
Andre,
There is just one small thing I don't like. In section 3.8
it says:
"Non-optional attributes MUST have a default value (which can be an empty string)."
We have found this rather inconvenient for the service discovery work where we often return values which are not optional but have no default value - for example the URL of a service. We have been obliged to give these default values of empty strings which is misleading - and is not even a valid URL (I think).
Would it break anything if this sentence were to be deleted?
I am sorry to bring this up at the last moment
Steve
-----Original Message----- From: saga-rg-bounces@ogf.org [mailto:saga-rg-bounces@ogf.org] On Behalf Of Andre Merzky Sent: 03 October 2007 21:37 To: SAGA RG Cc: Gregory Newby; Shantenu Jha Subject: [SAGA-RG] saga core spec - final call
Hi group(s),
the deed is done, finally, and we incorporated all public comments back into the SAGA spec, and then some. And then some more.
So, we would like to have a one week final call within the SAGA groups before we resubmit to the OGF editor. So, please, have a look at the document(s), and raise your voice if there is something you don't agree with. There are no open known issues at the moment, no TODO's and no FIXME's. But the text needs reviewing from a native (or good) English speaker, and also needs some formatting fixes. Shantenu and Thilo agreed to help with that, but more volonteers are VERY welcome!
I attach two versions of the document: the clean version which is to be resubmitted, and a version which includes markup of the changes. The markup semantics is:
red : removed green : fixed blue : added
For large parts of the text (the verbatim sections), you'll find diff style markups
+ : added ! : fixed - : removed
I'll try to come up with a detailed change log tomorrow or Friday, which should help you to understand the evolution of the document.
BTW, the spec grew bigger again, but mostly because of added details, and not of added semantics.
Cheers, Andre
PS.: we know of course that a one week final call is short, but we would _really_ like to get the spec out of the door by OGF21. If you have concerns about the short call, please let us know!
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced. -- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.
participants (5)
-
'Andre Merzky' -
Andre Merzky
-
Ceriel Jacobs -
Fisher, SM (Steve) -
Hartmut Kaiser