Fwd (schuett@zib.de): Re: SAGA Strawman API
Hi group, Thorsten sent me some feedback to the strawman API. Since it is in german, I'll translate it to english for the list. Some parts I leave out: those which point out small obvious errors like spelling etc, which I just corrected in the doc. Thanks for the comments, Thorsten! On Friday 20 May 2005 18:47:11, Thorsten Sch"uett wrote:
Mal abgesehen davon, dass ich noch nie von SIDL gehört habe ...
- Warum brauche ich im Package NameSpace ein interface NSDir? Sollte das Ding nicht Directory heissen?
Q: Why does the package NameSpace need a interface NSDir? Shouldn't that be named Directory? A: It WAS named directore before, but we thought Dir to be, well, shorter, w/o loosing meaning. Hmm, I prefer Dir for beeing shorter, but have no strong opniion about it. Others?
- Ist isFile und isLink nicht wieder arg File spezifisch? In einem LDAP-Baum hasst du bestimmt andere isXXX-Funktionen. isDir kann bleiben. Gibt es Links in jedem Namespace?
Q: Isn't isFile and isLink too FILE specific? In an LDAP tree you might find completely different isXXX methods. isDir is ok. Are there inks in all namespaces? A: isFile _sounds_ file specific, but that is a naming problem here. I have to elaborate on this somewhat, sorry. Once we had a NSDirectory and an NSDirectoryEntry interface. The latter one was basically empty, but in any package implementing NS, that would get filles. E.g. a physical file namespace would have a physical file as NSDirectoryEntry. Since that interface was empty, we got rid of it for now (just to be minimalistic). We figured: if we find good reasons (say: methods) for it to exist, we just include it again. Now that left is no good choice for naming the isEntry w/o creating confusion, so we named it isFile. Basically, that checks if the entry is, well, an entry. So, maybe the name _should_ return after all. For links: most name spaces have link. If not, then the is does not hurt. However, that method seems more related to the namespace concept than to its physical representation - thats why it is in the NS interface. Does that make sense?
- Impliziert der openDir-Call irgendwas für das Current working directory von der neuen Directory-Instanz?
Q: Is the openDir call indicatind anything in respect to the CWD of the new directory? A: Good catch! Yes, the CWD is pointing to the opened directory. I changed the doc.
- Was ist das Current working directory von NSDir("/")?
Q: what is cwd of NSDir("/"); A: "/".
- Irgendwie sind die Flags merkwürdig. Ich könnte ein Flags-Array mit Create und NoCreate erzeugen. Es würde dann zwar ein Exception geworfen, aber sowas kann auch der Compiler überprüfen. Lass doch die NoXXXX Flags weg und mach flags zu einem set<openFlags>. Dann gibt es auch keine doppelten Flags. Und wenn ihr schon numerische Werte für die Flags einführt, gestalte sie doch so, dass man auch ein einen Integer und Bit-Arithmetik in einem Binding verwenden kann. enum openFlags{ Create = 1, Excl = 2, Truncate = 4, Append = 8, Lock = 16 };
Q: Flags are strange: I could create a flagg array with both 'Create' and 'NoCreate'. Well, thats would give an exception, but thats something which could be catched by the compiler. You could leave out the NoXXX flags, and change the flags to set<openFlags>. the there are no double flags. And if you go for numeric values, you could do the usual bit arithmetik thingie... A: I agree. I can't for sure remember the rationale for the current notation -- but I think we left that to the language binding. So, in C we would do what you suggest.
- Ist irgendwo definiert, wie gross ein long sein muss? Gerade für Grids sollte getSize mindestens 64-Bit zurückgeben.
Q: Is there any definition for sizeof (long)? In particular for Grids, getSize should return at least 64 bit. A: SIDL defines long to be 64bit. I will put the SIDL documentation on the WIKI.
- read: Posix kennt kein EndOfFile-Error. Dann wird einfach 0 zurückgegeben.
Q: in posix, there is no EOF error - just returns 0. A: Oops! removed.
- interface Attribute: Komischer Name, beschreibt das Interface nicht eher eine "Description" o.ä.? removeAttribute wird nicht genauer beschrieben. Mit eurem Interface kann man zu einem Key nicht mehrere Values haben. Schade.
Q: Interface Attributes: strange name, isn't that rather a description or such? removeAttribute is not fleshed out. You can't have multiple values for one key - a pity. A: Hmm, maybe we didn't transport the idea well enough. Think physical files: attributes would be for example: file size, file type, last mod time, owner, ACL etc. You don't have two values for size. If you have more than one item to one key (acl), you have vector attributes for these. I am not sure what you mean with description, or with multiple values in that context. Do you have an example? removeAttribute: Oops, fixed.
- In den Beispielen taucht manchmal "Context" auf. Im Text wird es glaube ich nicht erläutert. Könnt ihr die Dinger nicht bitte komplett eleminieren?
Q: In some examples appears a 'context' - this is not elaborated elsewhere in the text. Cant you remove them completely? A: A context is supposed to be a SAGA session handle. But, you are right, until they are fleshed out in the spec, they should go away in the examples. Thanks again, Andre.
Thorsten
----- End forwarded message ----- -- +-----------------------------------------------------------------+ | 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 Friday 20 May 2005 19:18, Andre Merzky wrote:
Q: Why does the package NameSpace need a interface NSDir? Shouldn't that be named Directory?
A: It WAS named directore before, but we thought Dir to be, well, shorter, w/o loosing meaning. Hmm, I prefer Dir for beeing shorter, but have no strong opniion about it. Others? NS is redundant and the meaning of Directory is more obvious than Dir.
- Irgendwie sind die Flags merkwürdig. Ich könnte ein Flags-Array mit Create und NoCreate erzeugen. Es würde dann zwar ein Exception geworfen, aber sowas kann auch der Compiler überprüfen. Lass doch die NoXXXX Flags weg und mach flags zu einem set<openFlags>. Dann gibt es auch keine doppelten Flags. Und wenn ihr schon numerische Werte für die Flags einführt, gestalte sie doch so, dass man auch ein einen Integer und Bit-Arithmetik in einem Binding verwenden kann. enum openFlags{ Create = 1, Excl = 2, Truncate = 4, Append = 8, Lock = 16 };
Q: Flags are strange: I could create a flagg array with both 'Create' and 'NoCreate'. Well, thats would give an exception, but thats something which could be catched by the compiler. You could leave out the NoXXX flags, and change the flags to set<openFlags>. the there are no double flags. And if you go for numeric values, you could do the usual bit arithmetik thingie...
A: I agree. I can't for sure remember the rationale for the current notation -- but I think we left that to the language binding. So, in C we would do what you suggest. Actually, you can't do the bit thingie in C. If you specify numerical values for the different flags, all bindings have to follow this specification.
Q: Interface Attributes: strange name, isn't that rather a description or such? removeAttribute is not fleshed out. You can't have multiple values for one key - a pity.
A: Hmm, maybe we didn't transport the idea well enough. Think physical files: attributes would be for example: file size, file type, last mod time, owner, ACL etc. You don't have two values for size. If you have more than one item to one key (acl), you have vector attributes for these. Ok, my fault. You can have multiple values for one key using the xxxVectorAttribute-Calls.
Regarding the name of the interface: I associate with "Attribute" one Key-Value-Pair but your interface represents a set of attributes. Thatswhy I think that the name is strange. Thorsten
Hi Thorsten, Quoting [Thorsten Schuett] (May 21 2005):
On Friday 20 May 2005 19:18, Andre Merzky wrote:
Q: Why does the package NameSpace need a interface NSDir? Shouldn't that be named Directory?
A: It WAS named directore before, but we thought Dir to be, well, shorter, w/o loosing meaning. Hmm, I prefer Dir for beeing shorter, but have no strong opniion about it. Others? NS is redundant and the meaning of Directory is more obvious than Dir.
We are using Directory for the NSDir incarnation of a physical file space already. For one that is probably the most common used context for directory. Also, the alternative would be PhysicalDirectory or PhysicalDir - both quite long. However, I see your point. Maybe we should rename it to 'Container' in the NameSpace package. Naming - the bottomless pit... *sigh* ;-)
Q: Flags are strange: I could create a flagg array with both 'Create' and 'NoCreate'. Well, thats would give an exception, but thats something which could be catched by the compiler. You could leave out the NoXXX flags, and change the flags to set<openFlags>. the there are no double flags. And if you go for numeric values, you could do the usual bit arithmetik thingie...
A: I agree. I can't for sure remember the rationale for the current notation -- but I think we left that to the language binding. So, in C we would do what you suggest. Actually, you can't do the bit thingie in C. If you specify numerical values for the different flags, all bindings have to follow this specification.
Good point - we should fix that then I guess...
Q: Interface Attributes: strange name, isn't that rather a description or such? removeAttribute is not fleshed out. You can't have multiple values for one key - a pity.
A: Hmm, maybe we didn't transport the idea well enough. Think physical files: attributes would be for example: file size, file type, last mod time, owner, ACL etc. You don't have two values for size. If you have more than one item to one key (acl), you have vector attributes for these. Ok, my fault. You can have multiple values for one key using the xxxVectorAttribute-Calls.
Regarding the name of the interface: I associate with "Attribute" one Key-Value-Pair but your interface represents a set of attributes. Thatswhy I think that the name is strange.
I see - would be more AttributeSet. But I guess we can leave the name - just have to make the idea more obvious. Thanks, Andre.
Thorsten
-- +-----------------------------------------------------------------+ | 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 | | +-----------------------------------------------------------------+
participants (2)
-
Andre Merzky -
Thorsten Schuett