Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John D. Heintz wrote: | [...] | Is this behavior currently part of Reiser4? I don't remember seeing it | anywhere, but I do remember reading something about inheritence being | needed for various features. Is this the same as inheritence? I don't know enough about how Reiser4 currently works. I last tried it a few months ago, although I might try it again soon. But in a few months, it becomes such a moving target that I think I'll have to read the whitepaper again. Just haven't gotten the time. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQH8xBngHNmZLgCUhAQKqfg//dpUOU53eoCQzseF1F2okf1BZRE42Ij37 n/e1T1HKg5llAo+IG8W8FZ25eEDzqM17Nt/ZuhdvjqMLYUp3kMBBLrZOpFhxmNNG boTnjDakjEu2BCm3xNYEGoURBqs0MNUz85h9inrYML694nL90OkzrVP0xQBhYKI6 EmmTXVsqk+IZZ52OworcqlqV60GjZUI7F3j6vTFyjQCWat8mEc8fbRqFgI2/NlDO U0W6GClZA3NAEInYdUS1iVjILlUKC68GhiCs8gdGMKDBYoiJuHus/kvwzNb7wMvC lkA/GvTDxT1ikzarL3XfCqRzzeKYcgSJw6a4N7tOptBt0p6bZa+YK5bE0/EXD5Yb /LVIQA6xG6MJxQZUgrt6UiNvbJEvr/N78oBrSdMfIY0mSIn+FZZmJqrTT67SjkF2 Rv5c5dxB9mItEJmC576cIQZ7FY+XSh3kjgkvQRYplwZeyFLeZU4thsiLBtn1ARi2 1jt0sNZzKiIYpqmTKDYXQJ0lfd/jRRWNNgQy0aGt4RaKT2T181TPKjlz92n2BbNQ +nf1nmMQ9rnw9VQ3HhiUrBAQS0ufAY33ztpD/2/OoNfwvOEAOnzjZJCY9+Nhlbxg mOQXr3aGrP1xm7wCYgTy7A1Q2z5U9AxV31/f8ELLwFxDlQrBIHYCr67W7WSIb4dH +a2HCw1q3Ls= =4vk3 -END PGP SIGNATURE-
Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John D. Heintz wrote: | Hans Reiser wrote: | |> John D. Heintz wrote: |> |>> |>> Does some sort of syntactic shorthand actually break the set |>> theoretic naming system rules? Or is this just something you view as |>> needless complexity? |> |> |> |> precisely what syntactic shorthand? | | | | | foo/nsa:permissions -> foo/nsa.gov/secure-linux/permissions | | This assumes a mapping from "nsa" -> "nsa.gov/security/". | | The characters up to the ':' would be looked up in a namespaces map, and | if found the substituion would occur before further name-> object | resolution. I don't think this breaks the goals set out in the "Future | Vision" white paper, but I guess that is exactly what I am asking you ;-) Since we are allowed "views", how about this: make foo/nsa a symlink to foo/nsa.gov. Or, alternatively, make foo/nsa/permissions a symlink to foo/nsa.gov/secure-linux/permissions. These symlinks would only exist for either the process (and its children) which established them, or for all children of the file with that linkfarm, I'm not sure which. In the first example, you'd do something like this: ln -s /..some.pseudo.file/nsa.gov/secure-linux/permissions \ /..some.pseudo.file/nsa/permissions (hoping it handles directory creation here) The problem here is only children of 'ls' are affected, meaning shell scripts don't work unless shells are modified, which is why I like this better: ln -s foo/nsa.gov/secure-linux/permissions foo/nsa/permissions now we have foo/nsa/permissions -> foo/nsa.gov/secure-linux/permissions but now, if foo is a directory, we also have foo/bar/nsa/permissions -> foo/bar/nsa.gov/secure-linux/permissions The only thing here is, if foo is a directory, we probably want to hide the whole construct somehow anyway. I'll leave that to others -- I joined this discussion a little too late to _really_ know what I'm talking about. Either way, some sort of shortcut (and I'm suggesting symlinks to keep it Unix) controlled from user-space keeps the main advantage of XML namespaces -- you can have much more than just "nsa.gov/secure-linux", but any arbitrary length you want, and users handle the namespace collisions for you (that would result from creating something like foo/permissions) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iQIVAwUBQHynAHgHNmZLgCUhAQI+Aw/8Cb8ocN1T/M5SUGi8Qd/nqimmxnSpFryh QDOPTvlnqfco2kaQUagmhMAKS8xTqrGmQgIHJ/UZDAAW+fyhDgketYEd+KTiNZ5N Ccod3/Yk1JuW81UvSTcvcRwbqq71UVXbldo5URWZfRYi5diUhEriphtKDlDRSG7V 7Dicm2LwmhZq6je8wr/AZ0ywRBLjU+28oeSmiJXFe4xKxVftrH532RXg26e72aYZ c4f3zblv2+c6kDtGjf6XL0ABTM7RkD0MHCxEcq0FcXz0wp75cQtlL8n31eoiD7at SRLBeq2lp8h/lLxhcl67X+zQ/PgC4p/3ZrKLZ341beiHkL2rj4RjZFt9lf751Hfz xA3SSE7h6abg6VyJEilpvb9SNKTMGULC1MBXKwibHaDXgHo62pdMSrcz9Cw+ihaz zyENAUW0V3OWL5YSIPpl0BFy7XPnSuaE2Z3+N3Nej34fWmrh+HzHErRk0foqlmhu vmQ8Q4bbaakoe/uJDeMu2XTpoNChe7b6vxOwYxB9mxh4T2VOnli9YhpQm1ky7U1f BQTfIYok5+Az17O8tvlGC09DUfIslqLtpHVh9IyXOOfem6EEMIB/EJA3qv2us+IY si4M7TbeYVGaVLN+DACKL7gr5BKH0QWRRD+WFrn7Vig8IZSWrTGCEiTR8AWfpVR4 J8fcsxM53Cc= =XGmI -END PGP SIGNATURE-
Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)
On Tue, 2004-04-13 at 22:31, [EMAIL PROTECTED] wrote: > On Tue, 13 Apr 2004 13:47:12 CDT, "John D. Heintz" said: > > foo/nsa:permissions -> foo/nsa.gov/secure-linux/permissions > > > > This assumes a mapping from "nsa" -> "nsa.gov/security/". Implementing a mapping "nsa" -> "nsa.gov/security/" does not remove the headache of what to do with a tarball containing a directory named "nsa". While domain names are assigned in a process that guarantees uniqueness, subdirectories in software distributions are not naturally subject to the same constraints. This invalidates much of the theory in this thread of discussion. (Of course, the likelihood of anyone other than Hans & al actually using a directory name www.namesys.com is more than sufficiently remote to be a non-problem. Remember Murphy's law? I think the pseudodirectory name "metas" will bite us in our metas. (Recall, "meta" is a Greek word meaning "behind" or "after", right? Aristotle's Metaphysics got its name because it was the tome after Physics, Nature.) People with startup businesses look for sexy names for their pets, and names like MetaCity are sexy. When all names like InfoSoft, UniSoft, MicroSoft etc ad nauseam are used up, combinations with meta might become the next wave any time. Directories named metas are certain to show up often enough to be of concern. The very same reasons why filesystem people talk about file metadata, apply to other people as well. It is not hard to imagine a source code control system calling some of its files "metafiles" or something similar. Both Spanish and Portuguese have "metas" as commonly used words meaning goals. This is another source of conflicting file and directory names. Tar file makers will swear that people installing a file system that do not allow arbitrary a-z names of length <= eight, deserve all the problems they get. They will refuse to have to learn by heart all the non-portable names in this category. System administrators don't want to have complaints from users just because some names consisting of only a-z characters are reserved. Especially if one of the users is their boss. They don't care how seldom the problem actually arises. They will simplify matters to the rule: "Reiser4 is not a general-purpose file system, there are some files it cannot store." Linux distributors, system administrators and tar ball maintainers will read eachother's minds, and the distributors will recompile the kernel with some punctuation character in the reserved name. The major distributors will look at eachother and agree on the same name. Their choice will be a good one, provided they find reiser4 interesting for their users. They won't care about Hans' aesthetic senses. In the mean time, the xml namespace theoreticians are close to making a good point: Any software maintainer (other than Hans & al) creating tarballs with files or directories named reiser4 deserve bad luck. And their number is close enough to zero. On the other hand, end users that have never used Linux and who dislike punctuation characters, dislike '/' no less. They want to be able to put '/' into the file names, like "Spending proposal 2004/3Q". But they usually never see a shell, and navigate the file system by clicking on one folder at the time. They will never grep the metadata. They will only see the metadata in specially tailored dialogs. Regards, Enrique Pérez-Terrón
Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)
On Tue, 13 Apr 2004 13:47:12 CDT, "John D. Heintz" said: > foo/nsa:permissions -> foo/nsa.gov/secure-linux/permissions > > This assumes a mapping from "nsa" -> "nsa.gov/security/". > > The characters up to the ':' would be looked up in a namespaces map, and > if found the substituion would occur before further name-> object > resolution. I don't think this breaks the goals set out in the "Future > Vision" white paper, but I guess that is exactly what I am asking you ;-) This needs to be done *very* carefully, as all sorts of ugliness can result from a user being able to muck about with the mappings. Anybody who's ever used a VMS system and fiddled with the values of the various SYS$WHATEVER values knows what I mean - and yes, there were security holes caused by software that made the rash assumption that the SYS$FOO variables weren't altered by the user. pgp0.pgp Description: PGP signature
Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)
Hans Reiser wrote: John D. Heintz wrote: Does some sort of syntactic shorthand actually break the set theoretic naming system rules? Or is this just something you view as needless complexity? precisely what syntactic shorthand? foo/nsa:permissions -> foo/nsa.gov/secure-linux/permissions This assumes a mapping from "nsa" -> "nsa.gov/security/". The characters up to the ':' would be looked up in a namespaces map, and if found the substituion would occur before further name-> object resolution. I don't think this breaks the goals set out in the "Future Vision" white paper, but I guess that is exactly what I am asking you ;-) John
Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)
John D. Heintz wrote: Hi Grant, No, I'm not familiar with this. I was trying to frame my questions strictly in terms of Reiser4 naming constructs (the '/' operator only). I only bring it up because extended attributes seem to have dealt with your mentioned problem, potential name conflicts, without trouble. They use a "." as name separator but it is immaterial. Do the extended attributes show up as file system paths? Or is there a separate API to access them? If they show up as paths then I think they are very loosely like what I'm talking about: a shorthand syntax that by convention disabiguates similiar names. They are invisible through normal POSIX API. They have new system calls: getxattr, setxattr, listxattr, and removexattr which get, set list, and remove extended attributes. Thanks for the reference, I'll look into this when time permits. John Thanks
Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)
John D. Heintz wrote: Hans Reiser wrote: John D. Heintz wrote: Hans Reiser wrote: Let me verify something: You are suggesting that the "metas" namespace be the entry point for all of the plugin namespaces? I had assumed that each plugin would create it's own. That does certainly reduce the scope of my problem. It can use metas, but what it does is up to it. metas is a style convention. Okay, that is what I thought originally. That still means that user defined names and plugin defined names can in general conflict though. this is the beauty of there being an official maintainer for reiserfs to handle such issues;-) I would have been much happier to hear some strategy would enable plugins names to disambiguate themselves from each other and user defined names. In practice you might be right that a few dozen plugins can be "officially" integrated without too much trouble. Also, this issue could be dealt with later as well - I don't think now is the only opportunity for addressing it. plugins are not created as easily as files;-), there will be few enough that I can manage the issue as it happens Yes, in the short to medium term you are probably right that you can deal with these issues as they happen. I'd like there to be some better way of dealing with resolving conflicts from unified namespaces then always "ask Hans". Does some sort of syntactic shorthand actually break the set theoretic naming system rules? Or is this just something you view as needless complexity? precisely what syntactic shorthand? Thanks for the replies, John Heintz -- Hans
Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)
Hans Reiser wrote: John D. Heintz wrote: Hans Reiser wrote: Let me verify something: You are suggesting that the "metas" namespace be the entry point for all of the plugin namespaces? I had assumed that each plugin would create it's own. That does certainly reduce the scope of my problem. It can use metas, but what it does is up to it. metas is a style convention. Okay, that is what I thought originally. That still means that user defined names and plugin defined names can in general conflict though. this is the beauty of there being an official maintainer for reiserfs to handle such issues;-) I would have been much happier to hear some strategy would enable plugins names to disambiguate themselves from each other and user defined names. In practice you might be right that a few dozen plugins can be "officially" integrated without too much trouble. Also, this issue could be dealt with later as well - I don't think now is the only opportunity for addressing it. plugins are not created as easily as files;-), there will be few enough that I can manage the issue as it happens Yes, in the short to medium term you are probably right that you can deal with these issues as they happen. I'd like there to be some better way of dealing with resolving conflicts from unified namespaces then always "ask Hans". Does some sort of syntactic shorthand actually break the set theoretic naming system rules? Or is this just something you view as needless complexity? Thanks for the replies, John Heintz
Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)
Hi Grant, No, I'm not familiar with this. I was trying to frame my questions strictly in terms of Reiser4 naming constructs (the '/' operator only). Do the extended attributes show up as file system paths? Or is there a separate API to access them? If they show up as paths then I think they are very loosely like what I'm talking about: a shorthand syntax that by convention disabiguates similiar names. Thanks for the reference, I'll look into this when time permits. John Grant Miner wrote: Are you familiar with the extended attribute name space? An extended attribute name has the form of namespace.attribute, eg. user.mime-type, trusted.md5sum, or system.posix_acl_access. Currently the user, trusted, and system extended attribute classes are defined; more may be defined in the future. User attributes may be assigned to files and directories for storing arbitrary additional information such as the mime type, character set or encoding of a file. The access permissions for user attributes are defined by the file permission bits. Trusted attributes are visible and accessible only to processes that have the CAP_SYS_ADMIN capability (the super user usually has this capability). Attributes in this class are used to implement mechanisms in user space (i.e., outside the kernel) which keep information in extended attributes to which ordinary processes should not have access. System attributes are used by the kernel to store system objects such as Access Control Lists and Capabilities. Read and write access permissions to system attributes depend on the policy implemented for each system attribute implemented in the kernel.
