Do xml-like namespaces make sense for Reiser4? (re: metas thread)

Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[John D. Heintz]

Hi all,

I work with XML quite a lot in my job and deal with XML namespaces 
often. While I think they have some problems in the XML world (poor 
integration with XML InfoSet) they might be useful for Reiser4 and they 
seem to play well with the Set Theoretic underlying models (as far as I 
can tell :).

Here's what I'm thinking:
Instead of `cat foo.txt/metas/uid`
it would be `cat foo.txt/reiser4:metas/uid` or perhaps `cat 
foo.txt/reiser4:uid`.

Here the "reiser4" shorthand would map to "http://www.namesys.com/v4" or 
whatever Hans and team decided.

The reiser4 namespace could be hardcoded or compiled in  and exposed via 
`cat /proc/fs/reiser4/namespace`.

Other namespaces could be added to files/directories and I'd assume 
something like:
`cat foo.txt/reiser4:namespaces` would list all the namespaces available 
for a particular file.
Something like:
reiser4    http://www.namesys.com/v4
streams   http://www.evil-empire.com/streams
snapcm   http://www.snapcm.com/snapcm

John D. Heintz

ps - SnapCM is the name of a versioned linking model that I developed 
some time ago and hope one day to build a plugin for Reiser4. I'm being 
optimistic listing it in the available namespaces. ;-)

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[Hubert Chan]

XML namespaces seems like overkill to me, but I'll let someone more
qualified say something more intelligent.  I just have one other
comment.

>>>>> "John" == John D Heintz <jheintz@pobox.com> writes:

[...]

John> Other namespaces could be added to files/directories and I'd
John> assume something like: `cat foo.txt/reiser4:namespaces` would list
John> all the namespaces available for a particular file.  Something
John> like:
John> reiser4 http://www.namesys.com/v4
John> streams http://www.evil-empire.com/streams
John> snapcm http://www.snapcm.com/snapcm

It's probably better to do:

# ls foo.txt/reiser4:namespaces
reiser4
streams
snapcm
# cat foo.txt/reiser4:namespaces/reiser4
http://www.namespaces.com/v4

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[Hans Reiser]

Mhy colon instead of / ?

There is no reason for it.  Implementing a storage layer to make XML 
storage more efficient might be commercially interesting, but XML is not 
what we should copy for namespace style.

Hans

John D. Heintz wrote:

> Hi all,
>
> I work with XML quite a lot in my job and deal with XML namespaces 
> often. While I think they have some problems in the XML world (poor 
> integration with XML InfoSet) they might be useful for Reiser4 and 
> they seem to play well with the Set Theoretic underlying models (as 
> far as I can tell :).
>
> Here's what I'm thinking:
> Instead of `cat foo.txt/metas/uid`
> it would be `cat foo.txt/reiser4:metas/uid` or perhaps `cat 
> foo.txt/reiser4:uid`.
>
> Here the "reiser4" shorthand would map to "http://www.namesys.com/v4" 
> or whatever Hans and team decided.
>
> The reiser4 namespace could be hardcoded or compiled in  and exposed 
> via `cat /proc/fs/reiser4/namespace`.
>
> Other namespaces could be added to files/directories and I'd assume 
> something like:
> `cat foo.txt/reiser4:namespaces` would list all the namespaces 
> available for a particular file.
> Something like:
> reiser4    http://www.namesys.com/v4
> streams   http://www.evil-empire.com/streams
> snapcm   http://www.snapcm.com/snapcm
>
> John D. Heintz
>
> ps - SnapCM is the name of a versioned linking model that I developed 
> some time ago and hope one day to build a plugin for Reiser4. I'm 
> being optimistic listing it in the available namespaces. ;-)
>
>


-- 
Hans

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[Hubert Chan]

>>>>> "Hans" == Hans Reiser <reiser@namesys.com> writes:

Hans> Mhy colon instead of / ?  There is no reason for it.  Implementing
Hans> a storage layer to make XML storage more efficient might be
Hans> commercially interesting, but XML is not what we should copy for
Hans> namespace style.

Interestingly enough, for a course that I'm taking, I have to write a
research proposal, and that's the topic I've chosen, more or less.
Basically, I'm proposing to export a filesystem interface to XML, so
that you can do XML querying straight through the filesystem.

I'll post the proposal to the list after I'm done.  Whether or not
actual research will come out of that proposal is a different question.
(I'd like to pursue it further, but it's out of my current research
area, so I would have to switch areas, or figure out how to mutate it to
look like an algorithms topic.)

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[John D. Heintz]

Ah, I didn't do a good job of explaining the key benefit that I see in 
something like this.

"foo.txt/reiser4:uid"
 is syntactic magic for
"foo.txt/www.namesys.com/meta/uid"

when "reiser:" means "www.namesys.com/meta/uid" and ignoring URI prefix.

To me this is all about
1) a correct mechanism to both unify namespaces
2) _and_ avoid name conflicts
3) _and_ keep nice short file paths.

The chance that somebody else is going to name a file "meta" or "metas" 
is really high, the chance that someone will name a file 
"www.namesys.com/meta" is really low. But I don't want to type that in 
all the time.

I've drank the cool-aid about unified namespaces, but I feel that naming 
conflicts is still way too big a problem to just say "it's not a big 
deal" over.

Thanks,
John

Hans Reiser wrote:

> Mhy colon instead of / ?
>
> There is no reason for it.  Implementing a storage layer to make XML 
> storage more efficient might be commercially interesting, but XML is 
> not what we should copy for namespace style.
>
> Hans
>
> John D. Heintz wrote:
>
>> Hi all,
>>
>> I work with XML quite a lot in my job and deal with XML namespaces 
>> often. While I think they have some problems in the XML world (poor 
>> integration with XML InfoSet) they might be useful for Reiser4 and 
>> they seem to play well with the Set Theoretic underlying models (as 
>> far as I can tell :).
>>
>> Here's what I'm thinking:
>> Instead of `cat foo.txt/metas/uid`
>> it would be `cat foo.txt/reiser4:metas/uid` or perhaps `cat 
>> foo.txt/reiser4:uid`.
>>
>> Here the "reiser4" shorthand would map to "http://www.namesys.com/v4" 
>> or whatever Hans and team decided.
>>
>> The reiser4 namespace could be hardcoded or compiled in  and exposed 
>> via `cat /proc/fs/reiser4/namespace`.
>>
>> Other namespaces could be added to files/directories and I'd assume 
>> something like:
>> `cat foo.txt/reiser4:namespaces` would list all the namespaces 
>> available for a particular file.
>> Something like:
>> reiser4    http://www.namesys.com/v4
>> streams   http://www.evil-empire.com/streams
>> snapcm   http://www.snapcm.com/snapcm
>>
>> John D. Heintz
>>
>> ps - SnapCM is the name of a versioned linking model that I developed 
>> some time ago and hope one day to build a plugin for Reiser4. I'm 
>> being optimistic listing it in the available namespaces. ;-)
>>
>>
>
>

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[John D. Heintz]

Hi Hubert,

Hubert,

I agree with you, but I don't think our suggestions are exclusive.

An "ls" can return the contents of the directory as you suggested and a 
"cat" could return tab and newline separated content. I'm using the 
ReiserFS /etc/passwd example as a template.

What you suggested would be a good first step, I was just trying to 
intuitively make my point.

Thanks,
John


Hubert Chan wrote:

>XML namespaces seems like overkill to me, but I'll let someone more
>qualified say something more intelligent.  I just have one other
>comment.
>
>  
>
>>>>>>"John" == John D Heintz <jheintz@pobox.com> writes:
>>>>>>            
>>>>>>
>
>[...]
>
>John> Other namespaces could be added to files/directories and I'd
>John> assume something like: `cat foo.txt/reiser4:namespaces` would list
>John> all the namespaces available for a particular file.  Something
>John> like:
>John> reiser4 http://www.namesys.com/v4
>John> streams http://www.evil-empire.com/streams
>John> snapcm http://www.snapcm.com/snapcm
>
>It's probably better to do:
>
># ls foo.txt/reiser4:namespaces
>reiser4
>streams
>snapcm
># cat foo.txt/reiser4:namespaces/reiser4
>http://www.namespaces.com/v4
>
>  
>

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[Hubert Chan]

>>>>> "John" == John D Heintz <jheintz@pobox.com> writes:

John> Hi Hubert, Hubert,

John> I agree with you, but I don't think our suggestions are exclusive.

John> An "ls" can return the contents of the directory as you suggested
John> and a "cat" could return tab and newline separated content. I'm
John> using the ReiserFS /etc/passwd example as a template.

Sigh.  Thanks for reminding me of that.  I guess it's still too easy to
get caught up in the old filesystem paradigms, even when you're talking
about the cool new features of Reiser4.

(Ha!  Just imagine how much trouble the regular users are going to
have, if us uber-hackers can't get it straight. ;-) )

-- 
Hubert Chan <hubert@uhoreg.ca> - http://www.uhoreg.ca/
PGP/GnuPG key: 1024D/124B61FA
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA
Key available at wwwkeys.pgp.net.   Encrypted e-mail preferred.

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[John D. Heintz]

Hans,

If I understand the naming system primitives correctly then the ":" 
introduces a new sequence operator and does evil things to closure, right?

Let's use an example that is likely to conflict: Security plugins 
introducing a name "permissions" to objects.

Here is my list of how to expose this:
1) foo.txt/permissions
 * likely to conflict with end-user names and other security provider names
2) foo.txt/white-hat-permissions
 * verbose, but negligible risk of conflicts
3) foo.txt/white-hat-security/permissions
 * nested namespace to provide isolation
4) foo.txt/<wh-sec>permissions
 * syntax implying substitution before name resolution
 * could be some other syntax like foo.txt/wh-sec:permissions

I don't like 1) or 2), and I also don't see much real difference between 
3) and 4).

I'm guessing that the syntax of 4) is problem: like the ":" is 
introduces new sequencial operations. I'm viewing it as just a syntactic 
shorthand with a clear translation to the actual name.

Thanks,
John


John D. Heintz wrote:

> Ah, I didn't do a good job of explaining the key benefit that I see in 
> something like this.
>
> "foo.txt/reiser4:uid"
> is syntactic magic for
> "foo.txt/www.namesys.com/meta/uid"
>
> when "reiser:" means "www.namesys.com/meta/uid" and ignoring URI prefix.
>
> To me this is all about
> 1) a correct mechanism to both unify namespaces
> 2) _and_ avoid name conflicts
> 3) _and_ keep nice short file paths.
>
> The chance that somebody else is going to name a file "meta" or 
> "metas" is really high, the chance that someone will name a file 
> "www.namesys.com/meta" is really low. But I don't want to type that in 
> all the time.
>
> I've drank the cool-aid about unified namespaces, but I feel that 
> naming conflicts is still way too big a problem to just say "it's not 
> a big deal" over.
>
> Thanks,
> John
>
> Hans Reiser wrote:
>
>> Mhy colon instead of / ?
>>
>> There is no reason for it.  Implementing a storage layer to make XML 
>> storage more efficient might be commercially interesting, but XML is 
>> not what we should copy for namespace style.
>>
>> Hans
>>
>> John D. Heintz wrote:
>>
>>> Hi all,
>>>
>>> I work with XML quite a lot in my job and deal with XML namespaces 
>>> often. While I think they have some problems in the XML world (poor 
>>> integration with XML InfoSet) they might be useful for Reiser4 and 
>>> they seem to play well with the Set Theoretic underlying models (as 
>>> far as I can tell :).
>>>
>>> Here's what I'm thinking:
>>> Instead of `cat foo.txt/metas/uid`
>>> it would be `cat foo.txt/reiser4:metas/uid` or perhaps `cat 
>>> foo.txt/reiser4:uid`.
>>>
>>> Here the "reiser4" shorthand would map to 
>>> "http://www.namesys.com/v4" or whatever Hans and team decided.
>>>
>>> The reiser4 namespace could be hardcoded or compiled in  and exposed 
>>> via `cat /proc/fs/reiser4/namespace`.
>>>
>>> Other namespaces could be added to files/directories and I'd assume 
>>> something like:
>>> `cat foo.txt/reiser4:namespaces` would list all the namespaces 
>>> available for a particular file.
>>> Something like:
>>> reiser4    http://www.namesys.com/v4
>>> streams   http://www.evil-empire.com/streams
>>> snapcm   http://www.snapcm.com/snapcm
>>>
>>> John D. Heintz
>>>
>>> ps - SnapCM is the name of a versioned linking model that I 
>>> developed some time ago and hope one day to build a plugin for 
>>> Reiser4. I'm being optimistic listing it in the available 
>>> namespaces. ;-)
>>>
>>>
>>
>>
>
>
>

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[Hans Reiser]

John D. Heintz wrote:

>
> Hans,
>
> If I understand the naming system primitives correctly then the ":" 
> introduces a new sequence operator and does evil things to closure, 
> right?
>
> Let's use an example that is likely to conflict: Security plugins 
> introducing a name "permissions" to objects.
>
> Here is my list of how to expose this:
> 1) foo.txt/permissions
> * likely to conflict with end-user names and other security provider 
> names

this would be foo/metas/permissions/owner, does that resolve the problem 
in your eyes?

> 2) foo.txt/white-hat-permissions
> * verbose, but negligible risk of conflicts
> 3) foo.txt/white-hat-security/permissions
> * nested namespace to provide isolation
> 4) foo.txt/<wh-sec>permissions
> * syntax implying substitution before name resolution
> * could be some other syntax like foo.txt/wh-sec:permissions
>
> I don't like 1) or 2), and I also don't see much real difference 
> between 3) and 4).
>
> I'm guessing that the syntax of 4) is problem: like the ":" is 
> introduces new sequencial operations. I'm viewing it as just a 
> syntactic shorthand with a clear translation to the actual name.
>
> Thanks,
> John
>
>
> John D. Heintz wrote:
>
>> Ah, I didn't do a good job of explaining the key benefit that I see 
>> in something like this.
>>
>> "foo.txt/reiser4:uid"
>> is syntactic magic for
>> "foo.txt/www.namesys.com/meta/uid"
>>
>> when "reiser:" means "www.namesys.com/meta/uid" and ignoring URI prefix.
>>
>> To me this is all about
>> 1) a correct mechanism to both unify namespaces
>> 2) _and_ avoid name conflicts
>> 3) _and_ keep nice short file paths.
>>
>> The chance that somebody else is going to name a file "meta" or 
>> "metas" is really high, the chance that someone will name a file 
>> "www.namesys.com/meta" is really low. But I don't want to type that 
>> in all the time.
>>
>> I've drank the cool-aid about unified namespaces, but I feel that 
>> naming conflicts is still way too big a problem to just say "it's not 
>> a big deal" over.
>>
>> Thanks,
>> John
>>
>> Hans Reiser wrote:
>>
>>> Mhy colon instead of / ?
>>>
>>> There is no reason for it.  Implementing a storage layer to make XML 
>>> storage more efficient might be commercially interesting, but XML is 
>>> not what we should copy for namespace style.
>>>
>>> Hans
>>>
>>> John D. Heintz wrote:
>>>
>>>> Hi all,
>>>>
>>>> I work with XML quite a lot in my job and deal with XML namespaces 
>>>> often. While I think they have some problems in the XML world (poor 
>>>> integration with XML InfoSet) they might be useful for Reiser4 and 
>>>> they seem to play well with the Set Theoretic underlying models (as 
>>>> far as I can tell :).
>>>>
>>>> Here's what I'm thinking:
>>>> Instead of `cat foo.txt/metas/uid`
>>>> it would be `cat foo.txt/reiser4:metas/uid` or perhaps `cat 
>>>> foo.txt/reiser4:uid`.
>>>>
>>>> Here the "reiser4" shorthand would map to 
>>>> "http://www.namesys.com/v4" or whatever Hans and team decided.
>>>>
>>>> The reiser4 namespace could be hardcoded or compiled in  and 
>>>> exposed via `cat /proc/fs/reiser4/namespace`.
>>>>
>>>> Other namespaces could be added to files/directories and I'd assume 
>>>> something like:
>>>> `cat foo.txt/reiser4:namespaces` would list all the namespaces 
>>>> available for a particular file.
>>>> Something like:
>>>> reiser4    http://www.namesys.com/v4
>>>> streams   http://www.evil-empire.com/streams
>>>> snapcm   http://www.snapcm.com/snapcm
>>>>
>>>> John D. Heintz
>>>>
>>>> ps - SnapCM is the name of a versioned linking model that I 
>>>> developed some time ago and hope one day to build a plugin for 
>>>> Reiser4. I'm being optimistic listing it in the available 
>>>> namespaces. ;-)
>>>>
>>>>
>>>
>>>
>>
>>
>>
>
>
>
>


-- 
Hans

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[John D. Heintz]

Hans Reiser wrote:

> John D. Heintz wrote:
>
>>
>> Hans,
>>
>> If I understand the naming system primitives correctly then the ":" 
>> introduces a new sequence operator and does evil things to closure, 
>> right?
>>
>> Let's use an example that is likely to conflict: Security plugins 
>> introducing a name "permissions" to objects.
>>
>> Here is my list of how to expose this:
>> 1) foo.txt/permissions
>> * likely to conflict with end-user names and other security provider 
>> names
>
>
> this would be foo/metas/permissions/owner, does that resolve the 
> problem in your eyes?
>

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.

I'm not sure it removes the problem though, it just pushes the 
bottleneck one level away. That is still a good thing: it removes those 
conflicts from user created names, but not from plugin suppliers.

What if two suppliers of security plugins wanted to expose 
"permissions"? I'm thinking of the GNOME or KDE file managers growing a 
GUI permisions dialog to edit the structure of  data/information in the 
permissions namespace.

If
# cat foo/meta/permissions
# WhiteHat open source LDAP security plugin
owner   jheintz
grant   some stuff...
....

then user applications (like GUI filemanagers) will start depending on 
that. (Or the sub-structure exposed as further names...) Do you not 
think this will cause problems when
# cat foo/meta/permissions
# NSA Cryptographic security plugin
authority   The Office of John Heintz
status    confidential
grant   some stuff...
....

If I didn't mind typing really long names I'd say the following is 
absolutely correct and gives no worry about naming conflict:
cat foo/metas/nsa.gov/permissions
cat foo/metas/whitehat.com/permissions

(But then again I'd say the following does as well:
cat foo/nsa.gov/permissions
cat foo/whitehat.com/permissions)

I just don't want to type more than I have to. Thanks for the replies,
John Heintz


>> 2) foo.txt/white-hat-permissions
>> * verbose, but negligible risk of conflicts
>> 3) foo.txt/white-hat-security/permissions
>> * nested namespace to provide isolation
>> 4) foo.txt/<wh-sec>permissions
>> * syntax implying substitution before name resolution
>> * could be some other syntax like foo.txt/wh-sec:permissions
>>
>> I don't like 1) or 2), and I also don't see much real difference 
>> between 3) and 4).
>>
>> I'm guessing that the syntax of 4) is problem: like the ":" is 
>> introduces new sequencial operations. I'm viewing it as just a 
>> syntactic shorthand with a clear translation to the actual name.
>>
>> Thanks,
>> John
>>
>>

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[Grant Miner]

John D. Heintz wrote:

> Hans Reiser wrote:
> 
>> John D. Heintz wrote:
>>
>>>
>>> Hans,
>>>
>>> If I understand the naming system primitives correctly then the ":" 
>>> introduces a new sequence operator and does evil things to closure, 
>>> right?
>>>
>>> Let's use an example that is likely to conflict: Security plugins 
>>> introducing a name "permissions" to objects.
>>>
>>> Here is my list of how to expose this:
>>> 1) foo.txt/permissions
>>> * likely to conflict with end-user names and other security provider 
>>> names
>>
>>
>>
>> this would be foo/metas/permissions/owner, does that resolve the 
>> problem in your eyes?
>>
> 
> 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.
> 
> I'm not sure it removes the problem though, it just pushes the 
> bottleneck one level away. That is still a good thing: it removes those 
> conflicts from user created names, but not from plugin suppliers.
> 
> What if two suppliers of security plugins wanted to expose 
> "permissions"? I'm thinking of the GNOME or KDE file managers growing a 
> GUI permisions dialog to edit the structure of  data/information in the 
> permissions namespace.
> 
> If
> # cat foo/meta/permissions
> # WhiteHat open source LDAP security plugin
> owner   jheintz
> grant   some stuff...
> ....
> 
> then user applications (like GUI filemanagers) will start depending on 
> that. (Or the sub-structure exposed as further names...) Do you not 
> think this will cause problems when
> # cat foo/meta/permissions
> # NSA Cryptographic security plugin
> authority   The Office of John Heintz
> status    confidential
> grant   some stuff...
> ....
> 
> If I didn't mind typing really long names I'd say the following is 
> absolutely correct and gives no worry about naming conflict:
> cat foo/metas/nsa.gov/permissions
> cat foo/metas/whitehat.com/permissions
> 
> (But then again I'd say the following does as well:
> cat foo/nsa.gov/permissions
> cat foo/whitehat.com/permissions)
> 
> I just don't want to type more than I have to. Thanks for the replies,
> John Heintz
> 
> 
>>> 2) foo.txt/white-hat-permissions
>>> * verbose, but negligible risk of conflicts
>>> 3) foo.txt/white-hat-security/permissions
>>> * nested namespace to provide isolation
>>> 4) foo.txt/<wh-sec>permissions
>>> * syntax implying substitution before name resolution
>>> * could be some other syntax like foo.txt/wh-sec:permissions
>>>
>>> I don't like 1) or 2), and I also don't see much real difference 
>>> between 3) and 4).
>>>
>>> I'm guessing that the syntax of 4) is problem: like the ":" is 
>>> introduces new sequencial operations. I'm viewing it as just a 
>>> syntactic shorthand with a clear translation to the actual name.
>>>
>>> Thanks,
>>> John
>>>
>>>
> 
> 

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.

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[Hans Reiser]

John D. Heintz wrote:

> Hans Reiser wrote:
>
>> John D. Heintz wrote:
>>
>>>
>>> Hans,
>>>
>>> If I understand the naming system primitives correctly then the ":" 
>>> introduces a new sequence operator and does evil things to closure, 
>>> right?
>>>
>>> Let's use an example that is likely to conflict: Security plugins 
>>> introducing a name "permissions" to objects.
>>>
>>> Here is my list of how to expose this:
>>> 1) foo.txt/permissions
>>> * likely to conflict with end-user names and other security provider 
>>> names
>>
>>
>>
>> this would be foo/metas/permissions/owner, does that resolve the 
>> problem in your eyes?
>>
>
> 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.

>
> I'm not sure it removes the problem though, it just pushes the 
> bottleneck one level away. That is still a good thing: it removes 
> those conflicts from user created names, but not from plugin suppliers.
>
> What if two suppliers of security plugins wanted to expose 
> "permissions"? I'm thinking of the GNOME or KDE file managers growing 
> a GUI permisions dialog to edit the structure of  data/information in 
> the permissions namespace.
>
> If
> # cat foo/meta/permissions
> # WhiteHat open source LDAP security plugin
> owner   jheintz
> grant   some stuff...
> ....
>
> then user applications (like GUI filemanagers) will start depending on 
> that. (Or the sub-structure exposed as further names...) Do you not 
> think this will cause problems when
> # cat foo/meta/permissions
> # NSA Cryptographic security plugin
> authority   The Office of John Heintz
> status    confidential
> grant   some stuff...
> ....

this is the beauty of there being an official maintainer for reiserfs to 
handle such issues;-)

plugins are not created as easily as files;-), there will be few enough 
that I can manage the issue as it happens

>
> If I didn't mind typing really long names I'd say the following is 
> absolutely correct and gives no worry about naming conflict:
> cat foo/metas/nsa.gov/permissions
> cat foo/metas/whitehat.com/permissions
>
> (But then again I'd say the following does as well:
> cat foo/nsa.gov/permissions
> cat foo/whitehat.com/permissions)
>
> I just don't want to type more than I have to. Thanks for the replies,
> John Heintz
>
>
>>> 2) foo.txt/white-hat-permissions
>>> * verbose, but negligible risk of conflicts
>>> 3) foo.txt/white-hat-security/permissions
>>> * nested namespace to provide isolation
>>> 4) foo.txt/<wh-sec>permissions
>>> * syntax implying substitution before name resolution
>>> * could be some other syntax like foo.txt/wh-sec:permissions
>>>
>>> I don't like 1) or 2), and I also don't see much real difference 
>>> between 3) and 4).
>>>
>>> I'm guessing that the syntax of 4) is problem: like the ":" is 
>>> introduces new sequencial operations. I'm viewing it as just a 
>>> syntactic shorthand with a clear translation to the actual name.
>>>
>>> Thanks,
>>> John
>>>
>>>
>
>
>


-- 
Hans

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[John D. Heintz]

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.
>
>

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[John D. Heintz]

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)

[Hans Reiser]

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)

[Grant Miner]

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]

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)

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 879 bytes --]

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.....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[Enrique Perez-Terron]

On Tue, 2004-04-13 at 22:31, Valdis.Kletnieks@vt.edu 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)

[David Masover]

-----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)

[John D. Heintz]

Enrique,

Enrique Perez-Terron wrote:
> On Tue, 2004-04-13 at 22:31, Valdis.Kletnieks@vt.edu 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".


A directory or file named "nsa" doesn't conflict with this scheme, look 
more closely at the left hand side: foo/nsa:permissions

foo/nsa/permissions wouldn't receive the same treatment and would 
instead just be a regular file or directory lookup.

Two conditions are necessary to trigger the syntactic manipulation I'm 
suggesting:
1) a ':' must be present in the name being resolved (i.e. nsa:permissions)
2) The prefix before the ':' must be in the mappings (i.e. nsa)

Only if both of those are present does anything special happen.

A tarball containing "secure-linux/nsa/src/*.c" wouldn't break anything, 
and is so likely that no suggestion should risk breaking this case.

However, a tarball containing "secure-linux/nsa:src/*.c" would indeed 
break my scheme. I'm suggesting this is an ignorably small likelyhood. 
Others are free to disagree with this of course.

John Heintz

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[John D. Heintz]

David,

I think you might be onto something, but doing this manually for each 
file isn't viable (in my opinion).

What I think might work is applying symlinks to all files hierarchically 
so that all "*/nsa/*" names resolve to "*/nsa.gov/security/*".

Can you explain more how views would contribute to this? I've read the 
proposal but don't yet see how they would work in practice.

Thanks for the reply.

John


David Masover wrote:
> -----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)

[Enrique Perez-Terron]

On Wed, 2004-04-14 at 17:06, John D. Heintz wrote:
> Enrique Perez-Terron wrote:
> > On Tue, 2004-04-13 at 22:31, Valdis.Kletnieks@vt.edu 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".
> 
> 
> A directory or file named "nsa" doesn't conflict with this scheme, look 
> more closely at the left hand side: foo/nsa:permissions

You are right, thank you.

> However, a tarball containing "secure-linux/nsa:src/*.c" would indeed 
> break my scheme. I'm suggesting this is an ignorably small likelyhood. 
> Others are free to disagree with this of course.

I agree.

Regards,
Enrique

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[David Masover]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John D. Heintz wrote:
| David,
|
| I think you might be onto something, but doing this manually for each
| file isn't viable (in my opinion).

It applies recursively.  Let's assume for a moment that /..foo is a
directory containing pseudo-files, metadata, or whatever the current
term is, for the file '/'.  By creating the file /..foo/something as a
symlink to /..foo/<some long path>/something, you automatically create
/bar/..foo/something, which is a link to /bar/..foo/<same long
path>/something.

| What I think might work is applying symlinks to all files hierarchically
| so that all "*/nsa/*" names resolve to "*/nsa.gov/security/*".

Just what I described above, only it is local to the tree I apply it to,
and files deeper in the hierarchy take precedence.  So, for example, if
I create a link manually for /bar/..foo/something that points somewhere
else, then /bar and all subdirs (and subfiles) of /bar contain that same
link, instead of the one created for /.

| Can you explain more how views would contribute to this? I've read the
| proposal but don't yet see how they would work in practice.

Views are an alternative proposal in which you create a mapping that
looks, feels, and smells like the symlink idea proposed above, only it
works for a single process.  The advantage here is you avoid stepping on
other people's toes, and it could be useful for programs.  However, most
users don't continue to use the same program every time to access the
filesystem, and may want something persistant.

I like the non-view solution best, but I think both are necessary -- the
views are to prevent separate programs accessing similarly named plugins
from stepping on each other's toes.  Imagine we have nsa.gov and
NoSlackingAcademy.com as two "namespaces", and two programs (or shell
scripts) want to simultaneously abbreviate each one to "nsa", on the
same file.

However, the view solution is nice for when a user has some plugin, say
from nsa.gov, that they use manually a lot ("echo 'bar' >
baz/..foo/security") and on almost every file.  It wouldn't affect any
programs that used different concepts, because they would always create
the links they needed first.

I am not sure how views actually work under the hood, so I don't know
how to implement it, but I would suggest that even when trying to make
typing easier, we need to hide these shortcuts somewhere, because
although it looks and acts like a symbolic link, this kind of shortcut
behaves very differently.  This '..metas' (among other suggestions)
sounds like exactly the thing needed here -- symlinks created in there
would be treated as namespace abbreviations and would be duplicated on
all children that didn't already have such a link already.

One more detail about "views" -- assuming we are using '..metas', on
creating a view for this purpose, all symlinks in '..metas' should be
removed, to avoid confusion.

By now I'm sure I've abused several concepts before learning what they
are.  Time to go check the whitepaper for updates...


|
| Thanks for the reply.
|
| John
|
|
| David Masover wrote:
|
| 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

iQIVAwUBQH3XHXgHNmZLgCUhAQJSJQ/+IZEMPe9d/zovn1JgRKhGe6cCNeX5c19D
2BDmYeCiXbmK+TtR9Q7KeS4nPE5RgvmEtkHZ00LoMTblxL9WNsRoQSCxJEEdTYGe
ioFEKbPVNmmrd7RJsYSQVx7+Dx299JmCoOHmUuB45raATdV6yzKNVb3I819xFtrI
cS4egyfMlIs4NQtq1GrrXMVXFCstiWuPsZcbbc78eTCIb0pTcs/mkWWcB9kl1VjQ
kWIrHR6Qb0epLKSR0NrqikQK3rT3sqA5IZNYqgiVIu1tO+grkzEyUydcrZZTYV8f
9ZM3OIy5rbuMn/Ki+TnTQCN4nQ71o/JzhuAQq73EHYmTwot9IYhJGb74SWfD2Usg
Tw9WvWzKaSo5ev261/6zQkIuvB0dvvt6FdbA2KR6ok1ckaJnVyeUjIqEAF42b5Dt
JMkR3DGHE+CyzL2sjPxQA3nCK5JZ4Osq/N6yQXnD+8nfPjqlv6hy1fzjlDLAdWJC
zGxBIpr7jKHfweE1zRCJlO+IpTokWibSw7E/oTSqZZKGGayXu/x+AFmQPY8N8cz/
PBkTgieqSKSUuIvNhetMvL8QPmqz3+eou9051aPSaf838NTTFA5D6JXkfAMhCaBb
9ji/QyQgp7QwrXX/yOB9h40zaSSIkm57IGo3LK74928wiLIkhhE9wh7aztgVQtcE
j2nbiT/XRzU=
=TEE5
-----END PGP SIGNATURE-----

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[John D. Heintz]

David Masover wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> John D. Heintz wrote:
> | David,
> |
> | I think you might be onto something, but doing this manually for each
> | file isn't viable (in my opinion).
> 
> It applies recursively.  Let's assume for a moment that /..foo is a
> directory containing pseudo-files, metadata, or whatever the current
> term is, for the file '/'.  By creating the file /..foo/something as a
> symlink to /..foo/<some long path>/something, you automatically create
> /bar/..foo/something, which is a link to /bar/..foo/<same long
> path>/something.
> 
> | What I think might work is applying symlinks to all files hierarchically
> | so that all "*/nsa/*" names resolve to "*/nsa.gov/security/*".
> 
> Just what I described above, only it is local to the tree I apply it to,
> and files deeper in the hierarchy take precedence.  So, for example, if
> I create a link manually for /bar/..foo/something that points somewhere
> else, then /bar and all subdirs (and subfiles) of /bar contain that same
> link, instead of the one created for /.
> 

Thanks for the explanation and I like the idea. Being able to define a 
symlink and have it recursively apply might be exactly what is needed here.

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?

Thanks,
John Heintz

Re: Do xml-like namespaces make sense for Reiser4? (re: metas thread)

[David Masover]

-----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-----