RE: ".meta." as a Name Prefix

RE: ".meta." as a Name Prefix

[Alexander G. M. Smith]

Burnes, James wrote on Wed, 21 Apr 2004 17:10:00 -0600:
> In the same way that 'ls <directory>' is ambigous.  Does it mean I want
> to look at the attributes of the directory itself, or does it mean that
> I'm referring to the contents of the directory?  That's why they
> invented 'ls -d'

Good analog.  There would have to be some OS and application level
changes to support having both read/writeable data and child objects.
For backwards compatiblity, calling ReadDir() would likely hint that
you want a list of child objects, and read() means you want the data.
The feature I want is that you can do both to any file system object.
Plus of course indexing of attributes and other BeOS style goodies.

- Alex

Re: "Metas"

[The Amazing Dragon]

> From: Grant Miner <mine0057@mrs.umn.edu>
> > I don't think I've heard a single person, except Hans,
> > voice any support for "metas".
> 
> I like "metas".

Chalk me up as neutral about the name itself. That is I'm neutral about
".metas" or "..metas", I'm firmly against using "metas" (or any other
name) without at least a leading period. I suspect Linus et al might very
well reject such a FS because this would be a fatal flaw. I'm concerned
about using such a short and therefore precious name for filesystem
functions, but OTOH it might well be accessed often by a user and
therefore appropriate.

> > It seems that the most widely supported name thus far
> > is "...".

> Maybe "props" would be a good name?  It is short for properties, which 
> is synonymous with metadata and attributes (oops, I used a heretical 
> word! :)

Might ".properties", ".metadata" or ".attributes" work? Programs
shouldn't have a problem with a 12 character string occuring once in
their code. From a shell you'll be able to use filename completion, or
11 characters isn't that many to type. (and the leading dot avoids
breaking zillions of programs with security implications)


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \   (    |         EHeM@cs.pdx.edu      PGP 8881EF59         |    )   /
  \_  \   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
    \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/

".meta." as a Name Prefix

[Alexander G. M. Smith]

Elliott Mitchell wrote on Fri, 16 Apr 2004 19:55:54 -0700 (PDT):
> > From: Grant Miner <mine0057@mrs.umn.edu>
> > I like "metas".
> 
> Chalk me up as neutral about the name itself. That is I'm neutral about
> ".metas" or "..metas", I'm firmly against using "metas" (or any other
> name) without at least a leading period. I suspect Linus et al might very
> well reject such a FS because this would be a fatal flaw. I'm concerned
> about using such a short and therefore precious name for filesystem
> functions, but OTOH it might well be accessed often by a user and
> therefore appropriate.

I agree, it needs to start with a period.  I'd also drop the idea
of having a separate directory for metadata and just use a common
name prefix.  ".meta.mime" for example, rather than ".meta/mime".

I'm probably repeating myself, but the trouble is that the .meta
directory isn't a full directory - you can't add attributes to it.
In BeOS, that's useful - the directory's GUI window coordinates
are stored as attributes on the directory.  I'd like to use the
standard GUI file explorer to also check on attributes!  With a
.meta directory, it seems good in a psychological organizational
way but it breaks the object model.  That breakage will cause more
programming annoyances than using a prefix instead, in my humble
opinion.

- Alex

Re: ".meta." as a Name Prefix

[David Masover]

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

Alexander G. M. Smith wrote:

| I agree, it needs to start with a period.  I'd also drop the idea
The namespace of beginning with one period is almost as full as that of
no periods, as mentioned before.  Our best bet for uniqueness is to call
it "reiser4metas" or something similar (.r4 or ..r4).

| of having a separate directory for metadata and just use a common
That's what we were doing before.  I didn't like it -- consider the use
on files:

touch foo
chmod +x foo
cd foo/
ls

You either get 'foo/' or an error message.  You do not get a list of all
the pseudo files available.  I'm sorry, but 'cat ..pseudo' just isn't a
viable substitute for ls.

Also, the only disadvantage from the user's point of view is an extra '/'.

| I'm probably repeating myself, but the trouble is that the .meta
| directory isn't a full directory - you can't add attributes to it.
What kind of attributes would you want to add?  And btw, check out what
is currently 'metas/metas'.  I don't know if that's actually functional
or just read-only, but it works.  And I also see no reason why (in raw
uneducated theory) a plugin couldn't be implemented to make it into a
full directory for certain files (and thus losing no functionality for
other files).

| standard GUI file explorer to also check on attributes!  With a
| .meta directory, it seems good in a psychological organizational
| way but it breaks the object model.  That breakage will cause more

It doesn't have to.  Look at how the "pure object-oriented" languages
work.  Many of them make everything some subclass of "object" -- even
classes themselves.  A class is an object of type class.  I'm not sure
how this is implemented in code, but in concept it works fine.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQIXHsngHNmZLgCUhAQLLlw//a6cy5K4mI0OGoDuyTSuaedI9TSy/GHEX
UBWBynKUBQ3CNrTQoQzvfOOZIGJXPvWPSSTS286KVCgXAeiWvjNvPwSReqmuajbl
T5jxHpTxFcU6H3BzKbDiYcpGiqifoRydjkcj5jMJkvW1GNEVHX358IZp3N+PzxE2
NCWqdQoO1+/rt0laxNK5EtGLWX0PD77Qfx/0FNh3/NKCOIEULOkUbXL7CJ3M9AEP
ysKUq5ZLDgqi4MS5YFnkyw95ZireHGKkJC49DmA/dpOvlFJdrCcZfwWjBtbwXk5K
znCTPJZlylSw7C8nFxDAylv5vlz8DNSNzZ0MuxtWQPGbah8FanYdVbaSbf0jmCXc
9uP1FHMGTO7PdhLY5conDiWtHuHFwNt4I3OvVxKzcFCtiRF19i9//mdSZeWt1GL9
xWonh6O7pODQP+C63+SLWGu38S1QgI6MNVSn9BvSiqZ8VaT1mcKrKU4Tp5e15PRp
l/Hr9n9BXeBdl/Pz/wzKnzzxCDQ13kEuZNkpHWw3KfGYokLdoc1yB702kJ6yP9pv
eU1c+1LUSOoaJV+iRfZt9OrJiNT+euHmH/ej+Nc6KXZpxmrPb7j0leery6xyfW+t
bU/jbmn/VcOVfDOyHim9MpIoBhBuvZIAurFyNW04ezMB97D9cj2P1oJHIrHoat6R
W/yNeXayRto=
=TYLn
-----END PGP SIGNATURE-----

Re: ".meta." as a Name Prefix

[John D. Heintz]

David Masover wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alexander G. M. Smith wrote:
> 
> | I agree, it needs to start with a period.  I'd also drop the idea
> The namespace of beginning with one period is almost as full as that of
> no periods, as mentioned before.  Our best bet for uniqueness is to call
> it "reiser4metas" or something similar (.r4 or ..r4).

On the trail to uniqueness I've got an idea that I'd like to send out. 
How about we introduce two pseudo names: one very unique and the other 
short and simple.

The first unique name is like a URN:
foo/urn:namesys.com:reiser4:meta/uid

This is certainly unique enough for automated tools to rely on, but I 
wouldn't want to type it all the time.

The second name is short and easy:
foo/metas/uid

This is easy to use but could conflict. It would also be very useful to 
be able to lookup and dynamically change the short name.

cat urn:namesys.com:reiser4:meta/shortName
echo "..meta" > urn:namesys.com:reiser4:meta/shortName

I don't know if this echo would change the short name for the whole 
filesystem, a single object, or hierachical override. Also, it is 
interesting to wonder about this change persisting.


> 
> | of having a separate directory for metadata and just use a common
> That's what we were doing before.  I didn't like it -- consider the use
> on files:
> 
> touch foo
> chmod +x foo
> cd foo/
> ls
> 
> You either get 'foo/' or an error message.  You do not get a list of all
> the pseudo files available.  I'm sorry, but 'cat ..pseudo' just isn't a
> viable substitute for ls.
> 
> Also, the only disadvantage from the user's point of view is an extra '/'.
> 
> | I'm probably repeating myself, but the trouble is that the .meta
> | directory isn't a full directory - you can't add attributes to it.
> What kind of attributes would you want to add?  And btw, check out what
> is currently 'metas/metas'.  I don't know if that's actually functional
> or just read-only, but it works.  And I also see no reason why (in raw
> uneducated theory) a plugin couldn't be implemented to make it into a
> full directory for certain files (and thus losing no functionality for
> other files).
> 
> | standard GUI file explorer to also check on attributes!  With a
> | .meta directory, it seems good in a psychological organizational
> | way but it breaks the object model.  That breakage will cause more
> 
> It doesn't have to.  Look at how the "pure object-oriented" languages
> work.  Many of them make everything some subclass of "object" -- even
> classes themselves.  A class is an object of type class.  I'm not sure
> how this is implemented in code, but in concept it works fine.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iQIVAwUBQIXHsngHNmZLgCUhAQLLlw//a6cy5K4mI0OGoDuyTSuaedI9TSy/GHEX
> UBWBynKUBQ3CNrTQoQzvfOOZIGJXPvWPSSTS286KVCgXAeiWvjNvPwSReqmuajbl
> T5jxHpTxFcU6H3BzKbDiYcpGiqifoRydjkcj5jMJkvW1GNEVHX358IZp3N+PzxE2
> NCWqdQoO1+/rt0laxNK5EtGLWX0PD77Qfx/0FNh3/NKCOIEULOkUbXL7CJ3M9AEP
> ysKUq5ZLDgqi4MS5YFnkyw95ZireHGKkJC49DmA/dpOvlFJdrCcZfwWjBtbwXk5K
> znCTPJZlylSw7C8nFxDAylv5vlz8DNSNzZ0MuxtWQPGbah8FanYdVbaSbf0jmCXc
> 9uP1FHMGTO7PdhLY5conDiWtHuHFwNt4I3OvVxKzcFCtiRF19i9//mdSZeWt1GL9
> xWonh6O7pODQP+C63+SLWGu38S1QgI6MNVSn9BvSiqZ8VaT1mcKrKU4Tp5e15PRp
> l/Hr9n9BXeBdl/Pz/wzKnzzxCDQ13kEuZNkpHWw3KfGYokLdoc1yB702kJ6yP9pv
> eU1c+1LUSOoaJV+iRfZt9OrJiNT+euHmH/ej+Nc6KXZpxmrPb7j0leery6xyfW+t
> bU/jbmn/VcOVfDOyHim9MpIoBhBuvZIAurFyNW04ezMB97D9cj2P1oJHIrHoat6R
> W/yNeXayRto=
> =TYLn
> -----END PGP SIGNATURE-----
> 
> 

Re: ".meta." as a Name Prefix

[David Masover]

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

|> cat urn:namesys.com:reiser4:meta/shortName
|> echo "..meta" > urn:namesys.com:reiser4:meta/shortName

Revisiting this idea:  this is a good idea for what happens _inside_ the
metas dir, for plugins.  But metas itself is a general enough,
well-enough designed and probably lasting concept that I think we can
use something like '...' or '..metas', or whatever is reasonably unique
_now_, and assume that once reiser4 hits mainstream usage, people will
be careful to develop around that name.

Inside the metas dir, though, we have plugins.  And if plugins could be
dynamic, even mostly in userspace, then we have the problem of plugins
becoming so popular that we have namespace collisions there.  I like
this solution, though -- it's kind of like the XML namespace concept,
something which should be in every language.

Using some mechanism, not sure what yet, you create a set of mappings:

meta/r4 -> meta/namesys.com/reiser4
meta/ -> meta/namesys.com/reiser4

They aren't really symlinks because the second option is for making all
children of meta/namesys.com/reiser4 available under meta/, so if you had:

meta/namesys.com/reiser4/bmap
meta/namesys.com/reiser4/plugin
meta/slaphack.com/happyface/:)

Now you have:

meta/bmap
meta/namesys.com/reiser4/bmap
meta/namesys.com/reiser4/plugin
meta/plugin
meta/slaphack.com/happyface/:)

More specific things would override less specific things, and in general
these mappings aren't allowed to touch anything that isn't itself a mapping.

I think you would use symlink() for setting these things up (cd meta; ln
~ -s namesys.com/reiser4 r4 || ln -s namesys.com/reiser4 .), and even if
they were completely dynamic, the files themselves would read like symlinks.

I heard someone say something like "reiser4 is almost shipped", so it
may be too late to send in ideas (especially ones which I've probably
said before), but I thought I'd drop this in anyway.  (sorry for the
noise if I _have_ said it before.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQItQOngHNmZLgCUhAQL9yhAAiaCH3ZxSS5T/VxgqW+Tk4jR3kjzA87Cq
dMfMFlGeS2R1X3p1nuqdb0Q8SWSvMV2cV/YgFXGq4BR+nMjTy/krm7AlXJ1Wj8ji
xORQMWWZAWsFTeIoQNgu1lDpTCfPISzsmEgLeYsq14UQn+cb8uZMIfy9/tmmY71N
W6XIsaW2hHp2LwgSsrIjZHthKZQ6WnQh0nsI/8JlU5hjJ4sbEh4SWMokDri//kGq
wiXk/489sx1u4k/ymU/CHZGSJA4c+/uBzW2QZ2qRnpa6uNwWtu/lqQhn28tkoHRw
k9TS9j0Ca0w/4k9UZFD8N1Lkxp52/XFTg+U+ZABzkIQx9VHC+nVgaVLIZSr31C4/
iTk+sHdY55kJtHOF8X7cSzx0D/V+Qo2owhOFS9B5/10NEv34UPmO4aQq9T/MeQVo
vqWF5L8h0N+zLqlTnkkf4zVBzALfTbsfk18fLeu42j8WZfkVBkHC5T2SBYjmuPHO
b3bNX1yl+xx0lFG4Wt6bz6sYhzmr2tOj1ayVEYdpZRsXZUsSwom5POeD5Yimuhd7
/VCiNhcNm17bfqOTK+e+36dE8c91YIyv32e3BBivrB2GYg1AgGfPuzMOky78GX/m
Ymh4ztKBAwoBytvsF4Aye+8h3bETBMjMoNhJT7EcvH/N4MFqtfZJLh6PafIXMIgA
IeMzRfndw1w=
=EGMz
-----END PGP SIGNATURE-----

Re: ".meta." as a Name Prefix

[Alexander G. M. Smith]

David Masover wrote on Sun, 25 Apr 2004 00:44:27 -0500:
> Inside the metas dir, though, we have plugins.  And if plugins could be
> dynamic, even mostly in userspace, then we have the problem of plugins
> becoming so popular that we have namespace collisions there.  I like
> this solution, though -- it's kind of like the XML namespace concept,
> something which should be in every language.

Actually the problem in real life (from BeOS experience) is the lack of
collisions.   Everybody keeps on prefixing their new attribute set with
a unique identifier (usually looking like "UNIQUER:attribute" in BeOS)
so you end up with redundancies like MAIL:subject and PINEAPPLE:subject
which should really be the same thing (since e-mail messages and UseNet
news are so similar and I want to search all subjects when looking
for a lost message).  Of course, this could be worked around by having
aliases of attribute names (sounds like another plugin), but it would
be nice if we had a standard set of attribute names.  Dublin core, anyone?

- Alex

Re: ".meta." as a Name Prefix

[John D. Heintz]

David,

Something I think I've understood from the code is that plugins aren't 
restricted to the metas directory. Any PSEUDO_PLUGIN can create a root 
name that is looked up everywhere.

That doesn't mean that PSEUDO_PLUGINs that do this will be accepted into 
the codebase or distributions, but there is no actual boundary between 
adding new names to foo/ instead of foo/metas.

John

David Masover wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> |> cat urn:namesys.com:reiser4:meta/shortName
> |> echo "..meta" > urn:namesys.com:reiser4:meta/shortName
> 
> Revisiting this idea:  this is a good idea for what happens _inside_ the
> metas dir, for plugins.  But metas itself is a general enough,
> well-enough designed and probably lasting concept that I think we can
> use something like '...' or '..metas', or whatever is reasonably unique
> _now_, and assume that once reiser4 hits mainstream usage, people will
> be careful to develop around that name.
> 
> Inside the metas dir, though, we have plugins.  And if plugins could be
> dynamic, even mostly in userspace, then we have the problem of plugins
> becoming so popular that we have namespace collisions there.  I like
> this solution, though -- it's kind of like the XML namespace concept,
> something which should be in every language.
> 
> Using some mechanism, not sure what yet, you create a set of mappings:
> 
> meta/r4 -> meta/namesys.com/reiser4
> meta/ -> meta/namesys.com/reiser4
> 
> They aren't really symlinks because the second option is for making all
> children of meta/namesys.com/reiser4 available under meta/, so if you had:
> 
> meta/namesys.com/reiser4/bmap
> meta/namesys.com/reiser4/plugin
> meta/slaphack.com/happyface/:)
> 
> Now you have:
> 
> meta/bmap
> meta/namesys.com/reiser4/bmap
> meta/namesys.com/reiser4/plugin
> meta/plugin
> meta/slaphack.com/happyface/:)
> 
> More specific things would override less specific things, and in general
> these mappings aren't allowed to touch anything that isn't itself a 
> mapping.
> 
> I think you would use symlink() for setting these things up (cd meta; ln
> ~ -s namesys.com/reiser4 r4 || ln -s namesys.com/reiser4 .), and even if
> they were completely dynamic, the files themselves would read like 
> symlinks.
> 
> I heard someone say something like "reiser4 is almost shipped", so it
> may be too late to send in ideas (especially ones which I've probably
> said before), but I thought I'd drop this in anyway.  (sorry for the
> noise if I _have_ said it before.)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iQIVAwUBQItQOngHNmZLgCUhAQL9yhAAiaCH3ZxSS5T/VxgqW+Tk4jR3kjzA87Cq
> dMfMFlGeS2R1X3p1nuqdb0Q8SWSvMV2cV/YgFXGq4BR+nMjTy/krm7AlXJ1Wj8ji
> xORQMWWZAWsFTeIoQNgu1lDpTCfPISzsmEgLeYsq14UQn+cb8uZMIfy9/tmmY71N
> W6XIsaW2hHp2LwgSsrIjZHthKZQ6WnQh0nsI/8JlU5hjJ4sbEh4SWMokDri//kGq
> wiXk/489sx1u4k/ymU/CHZGSJA4c+/uBzW2QZ2qRnpa6uNwWtu/lqQhn28tkoHRw
> k9TS9j0Ca0w/4k9UZFD8N1Lkxp52/XFTg+U+ZABzkIQx9VHC+nVgaVLIZSr31C4/
> iTk+sHdY55kJtHOF8X7cSzx0D/V+Qo2owhOFS9B5/10NEv34UPmO4aQq9T/MeQVo
> vqWF5L8h0N+zLqlTnkkf4zVBzALfTbsfk18fLeu42j8WZfkVBkHC5T2SBYjmuPHO
> b3bNX1yl+xx0lFG4Wt6bz6sYhzmr2tOj1ayVEYdpZRsXZUsSwom5POeD5Yimuhd7
> /VCiNhcNm17bfqOTK+e+36dE8c91YIyv32e3BBivrB2GYg1AgGfPuzMOky78GX/m
> Ymh4ztKBAwoBytvsF4Aye+8h3bETBMjMoNhJT7EcvH/N4MFqtfZJLh6PafIXMIgA
> IeMzRfndw1w=
> =EGMz
> -----END PGP SIGNATURE-----
> 
> 

Re: ".meta." as a Name Prefix

[David Masover]

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

| David,
|
| Something I think I've understood from the code is that plugins aren't
| restricted to the metas directory. Any PSEUDO_PLUGIN can create a root
| name that is looked up everywhere.

Thank you for that clarification, though I'm not sure it's relevant
here.  Try replacing my use of "meta" in those examples with "foo".

Also, someone mentioned that a lack of namespace collisions was more of
a problem than the collisions themselves -- that everyone tries to make
a unique name, and comes up with many copies of the same thing which
really should be the same.  I'd suggest that it's better to have a bunch
of redundant but working plugins than a bunch of intuitive and
non-redundant but occasionally failing plugins.

| That doesn't mean that PSEUDO_PLUGINs that do this will be accepted into
| the codebase or distributions, but there is no actual boundary between
| adding new names to foo/ instead of foo/metas.

As far as what's accepted, I can't imagine that there'd be so much
complexity in the "standard" plugins that no one could go and check for
redundancy, and communicate with the plugin authors about it.

|
| John
|
| David Masover wrote:
|
| |> cat urn:namesys.com:reiser4:meta/shortName
| |> echo "..meta" > urn:namesys.com:reiser4:meta/shortName
|
| Revisiting this idea:  this is a good idea for what happens _inside_ the
| metas dir, for plugins.  But metas itself is a general enough,
| well-enough designed and probably lasting concept that I think we can
| use something like '...' or '..metas', or whatever is reasonably unique
| _now_, and assume that once reiser4 hits mainstream usage, people will
| be careful to develop around that name.
|
| Inside the metas dir, though, we have plugins.  And if plugins could be
| dynamic, even mostly in userspace, then we have the problem of plugins
| becoming so popular that we have namespace collisions there.  I like
| this solution, though -- it's kind of like the XML namespace concept,
| something which should be in every language.
|
| Using some mechanism, not sure what yet, you create a set of mappings:
|
| meta/r4 -> meta/namesys.com/reiser4
| meta/ -> meta/namesys.com/reiser4
|
| They aren't really symlinks because the second option is for making all
| children of meta/namesys.com/reiser4 available under meta/, so if you
| had:
|
| meta/namesys.com/reiser4/bmap
| meta/namesys.com/reiser4/plugin
| meta/slaphack.com/happyface/:)
|
| Now you have:
|
| meta/bmap
| meta/namesys.com/reiser4/bmap
| meta/namesys.com/reiser4/plugin
| meta/plugin
| meta/slaphack.com/happyface/:)
|
| More specific things would override less specific things, and in general
| these mappings aren't allowed to touch anything that isn't itself a
| mapping.
|
| I think you would use symlink() for setting these things up (cd meta; ln
| ~ -s namesys.com/reiser4 r4 || ln -s namesys.com/reiser4 .), and even if
| they were completely dynamic, the files themselves would read like
| symlinks.
|
| I heard someone say something like "reiser4 is almost shipped", so it
| may be too late to send in ideas (especially ones which I've probably
| said before), but I thought I'd drop this in anyway.  (sorry for the
| noise if I _have_ said it before.)
|>
|>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQIwSnHgHNmZLgCUhAQLBIhAAkTsQLoQBBpQDHzX7HE6oc1j5s4D2oqcy
7tmBEtD5IeDERB37winb2EghAOnWXwNEHVSnQKkxmBJfttKytP2mv3UT077d+qEZ
xhCCHGMSA1EI+TyrgZVJsp8Qy34M8ciYTWoA97Cy8LOtou26YDxCZYVfB5j3PTkx
RTF9QB3F9ZcPu9HqYTpHQ5TqAyqzneZyHJYPPxI9ctWfbuJwKUUifz0CQ/1aY31L
IeV4vhGCMAPGGLF/Ll7d4q9VrrCxNQSfvxKmIK7ZSlo3gip4lxNOskRChXWEw7sR
Fng0kbsYAHkdtWfW/rP8NJe/YWgZsb+sldk/6M8zf5C8qssvU4lwOgyDSOBHqDtO
Lb+RCvJXBPJjeeRBM9RY8sLHVt9ie2uXC5hVVegynpMlMdN0lE81CCeeF9YtxA4F
icrQA6rtuOISY7Kw43v2P25/dHs9ZmsId1kV3gsVNMBi29wiRIru1lBdRuiJCZjg
yccDm53sZw46eq8ghuJ9niKyr9Unhnyz+RiJrJKr1v6juwm8YK3MnBr+RZwZRDei
FCfzScRp2rOz0gCXPKWBpt37Bv+ecAPn81gmL+wh+upY78FWqD5taPSZfq/1IGZQ
lnk5tSGQmS2lAfBjFnvCsUNmh/RFExpJew+zDbvHzsZy+G8JXb0VsPbxOJIjt0Bp
SUZZQQrya+0=
=o3i3
-----END PGP SIGNATURE-----

Re: ".meta." as a Name Prefix

[Alexander G. M. Smith]

David Masover wrote on Tue, 20 Apr 2004 20:00:34 -0500:
> That's what we were doing before.  I didn't like it -- consider the use
> on files:
> 
> touch foo
> chmod +x foo
> cd foo/
> ls
> 
> You either get 'foo/' or an error message.  You do not get a list of all
> the pseudo files available.  I'm sorry, but 'cat ..pseudo' just isn't a
> viable substitute for ls.

Why wouldn't that work?  I must have missed something.  I can see that
the fildirute (combined file / directory / attribute) nature of the new
file system objects making the old rwx flags obsolete (does the "x" flag
make it an executable file or does it mean permission to change directory
to the child objects of the file).  But if you change directory to a thing,
it gets appended to your path and the OS should be able to figure out that
you want to look at its child objects (which I'd prefer to directly
include things named .meta.blah, while others want a .metas subdirectory
as a child object).


> | I'm probably repeating myself, but the trouble is that the .meta
> | directory isn't a full directory - you can't add attributes to it.
> What kind of attributes would you want to add?

GUI directory display attributes, like window position and size,
background picture, when displaying that directory.

>  And btw, check out what is currently 'metas/metas'.

I couldn't find that.  Instead I noticed "/filename/metadata/stat/owner"
in http://www.namesys.com/v4/v4.html which seems a bit odd.  I'd expect
something like "/filename/metadata/stat/metadata/owner" if you were using
a metadata magic directory.  Or in my .meta. name prefix scheme, it
would be "/filename/.meta.stat/.meta.owner"

> I don't know if that's actually functional or just read-only, but it
> works.  And I also see no reason why (in raw uneducated theory) a
> plugin couldn't be implemented to make it into a full directory for
> certain files (and thus losing no functionality for other files).

Sounds like extra work and complexity, just to keep the idea of having
a magic subdirectory child object rather than just putting the meta
attributes directly as child objects.

> It doesn't have to.  Look at how the "pure object-oriented" languages
> work.  Many of them make everything some subclass of "object" -- even
> classes themselves.  A class is an object of type class.  I'm not sure
> how this is implemented in code, but in concept it works fine.

In that kind of class system every object is an object, and you can
do all object type operations to it (such as finding it's class name).
The magic .meta directory breaks that very concept by not implementing
full file system object functionality.  It's not a first class object,
it's an awkward special case.

- Alex

Re: ".meta." as a Name Prefix

[David Masover]

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

| David Masover wrote on Tue, 20 Apr 2004 20:00:34 -0500:
|
|>That's what we were doing before.  I didn't like it -- consider the use
|>on files:
|>
|>touch foo
|>chmod +x foo
|>cd foo/
|>ls
|>
|>You either get 'foo/' or an error message.  You do not get a list of all
|>the pseudo files available.  I'm sorry, but 'cat ..pseudo' just isn't a
|>viable substitute for ls.
|
|
| Why wouldn't that work?  I must have missed something.  I can see that
| the fildirute (combined file / directory / attribute) nature of the new
| file system objects making the old rwx flags obsolete (does the "x" flag
| make it an executable file or does it mean permission to change directory
| to the child objects of the file).  But if you change directory to a
thing,
| it gets appended to your path and the OS should be able to figure out that
| you want to look at its child objects (which I'd prefer to directly
| include things named .meta.blah, while others want a .metas subdirectory
| as a child object).

I imagine that's how it _should_ be implemented, but right now, I can ls
foo/metas, but not foo/.  Of course, I wouldn't expect to find anything
there, anyway...
|
|
|>| I'm probably repeating myself, but the trouble is that the .meta
|>| directory isn't a full directory - you can't add attributes to it.
|>What kind of attributes would you want to add?
|
|
| GUI directory display attributes, like window position and size,
| background picture, when displaying that directory.

I'm finding it hard to imagine where that would be really useful.  I
mean, users are mostly going to be using tools other than a file browser
to view it.  But that's just me -- it's clear in the whitepaper that
Hans is making a general purpose FS, and it's up to us to decide how to
use it.

|> And btw, check out what is currently 'metas/metas'.

Maybe I'm on an older snapshot?  I can currently do 'ls metas/metas' on
one box, but the kernel is 4 days old.

|
|
|>It doesn't have to.  Look at how the "pure object-oriented" languages
|>work.  Many of them make everything some subclass of "object" -- even
|>classes themselves.  A class is an object of type class.  I'm not sure
|>how this is implemented in code, but in concept it works fine.
|
|
| In that kind of class system every object is an object, and you can
| do all object type operations to it (such as finding it's class name).
| The magic .meta directory breaks that very concept by not implementing
| full file system object functionality.  It's not a first class object,
| it's an awkward special case.

I'm thinking things like inheritance, implemented the way I would/will
when I get the time to understand/write languages better.  Sure I can
find the class name of any object -- but not all objects have a class
name, and in fact, some of them will probably just reurn "Object" -- not
because the name is there in that particular object, but because it was
present in the original Class object.

Let's say you can do anything to .meta that you can to a normal
directory, but until you actually make a change to it that doesn't make
sense in the context of a "magic directory", it becomes a true child
object.  The same concept as Copy On Write.  Maybe even do it on a
per-item basis -- try to change the mode of the directory, and it
becomes a magic directory with a mode.  Try to make a (new) file in it,
and it becomes a nearly real directory with a mode and a file.  And so
on.  (At a certain point, of course, it has its own child directory.)

It also doesn't make sense for them to be directories in every sense of
the word by default.  One thing reiserfs/reiser4 is very good at now is
gajillions of tiny files -- files of 100-200 _bytes_.  To add a
directory on to every little file doesn't make sense, at least for
storage.  And making it possible to accidentally add such a directory
should at least allow for that directory to be removed later (if I
create foo/.meta/file and then remove it, foo should be as it was
before, except for maybe a timestamp)

Again, there are implementation details that I'm not sure of, because my
concepts for language design are mostly for some sort of
ruby/perl/python, only compiled better than C is.  I'm not implementing
any new projects for awhile, though -- I'm still in high school, so if I
do get time, I should spend it learning why I'm wrong.

Being loud, stupid, and long-winded on mailing lists is just one way I
find out why I'm wrong.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQItMKHgHNmZLgCUhAQJhzw/7B6p9n4ePCa3JYRtQbYTwm1CkXTpZcxpW
qEc7SgBmaZ6NWxBYWiAF/1MdOQloXjmOT+FnBCm9aAf5gwBi4UU9ES4Bg3pW2uKs
U2C02ekYW5k6p3DIi1iZPrZuqWW5Onpv+W3JujJETzl+4dojnfFR6lLhhmWWh1Iu
F7l4tg78968ibAwBZPC70bvNqwI+nhWLQwXNe5ZM2PbBNnfWcj//B/LZ78N5Up7G
qKnT9ftJCUqQXJL0tA409LNIjmeOJy24Nluqtcx6qphx6W4qBo7x1uzSNh3M+SfF
QPwewBHT0BR42qbWQxy4m1MwjWj6ktkmWzp+OhPg81sxb/iZF+oCBiw6U3phi97y
lyNtRy7w7yohGtQlVG2H8BYDAlZTXZiUcNUEzdV+3NjirBAbmotWtRuntf8wMdj6
Z749u7vS7xJi8wUHegBuzuvFQjlLnZIGdfHpCJ44+18wH2RfZWk+CPRKQBIrsbLE
9f/S/yi9lC/KYURpKvSExqCmEtGasksF6aIFb7Hr7p/vONBw/SntHuqxBN3/nIv4
AB4x5xKaxYpf5XI9fMbDlixASFz6gAE/5h6vRGbdL6ZKel6XqMaADRFDpfr9gY8Z
3t7fLE9p/KqeGRauhPLhohv5/z+MdnJPOhGyOB9XJfuBW8cEgfD0WkZKyXzAL7pL
QaCZzaj+fMw=
=z9qA
-----END PGP SIGNATURE-----