Re: reiser4 plugins

[Hubert Chan <hubert@uhoreg.ca>]

On Tue, 28 Jun 2005 02:01:12 -0400, Kyle Moffett <mrmacman_g4@mac.com> said:

> On Jun 28, 2005, at 01:30:08, Hubert Chan wrote:
>> On Tue, 28 Jun 2005 00:38:38 -0400, Kyle Moffett
>> <mrmacman_g4@mac.com> said:
>>> Ok.  Those things should probably be divided up.  Stuff like POSIX
>>> extended attributes and such that have existing interfaces should
>>> use those.
>>  One of the claimed advantages of the '...' interface is that
>> everything is editable as a file.  So if someone wanted to edit the
>> description extended attribute for foo.txt, he would just run
>> "[editor] foo.txt/.../description" (or "[editor]
>> /meta/fs/$(getattrpath foo.txt)/description"), instead of needing to
>> use some special purpose editor.  It works well for things like being
>> able to use Gimp to edit a thumbnail or icon attribute.

> I don't disagree with the thumbnail/icon/description, but things like
> POSIX acls and extended attributes have _existing_ interfaces which
> should be used.

OK.  I agree with that.  Of course, Reiser4 can always present both
interfaces, just like it presented two interfaces to the stat data --
the regular interface and the metas (now '...') interface -- before
file-as-dir got disabled by default.

> I don't deny them the right to add other interfaces later, but such
> should be a secondary or tertiary patch, after the rest of the stuff
> is in.  In any case, if we were to provide an interface by which one
> could $EDITOR the POSIX ACLs, it should be done in the VFS where all
> filesystems can share it.

I don't know if VFS is the right place for it, but I agree that it would
be good to make it accessible to all filesystems.

>> The inspiration, I think, was the MacOS X/NeXTSTEP bundle format.
>> For example, MacOS X/NeXTSTEP .app file is actually a directory that
>> behaves much like an executable file (double-clicking a .app file in
>> the Finder launches the application, instead of opening the
>> directory).  However, it is in reality a directory that contains many
>> things that could be thought of as extended attributes (such as the
>> application icon, information about the application, etc.).  Since
>> the application icon is a real file, it can be edited by normal
>> graphics editors (not like Windows programs, where you need a special
>> icon editor).  And since it's inside the .app directory, it's
>> attached to the application (not like Linux, where the program is in
>> /usr/bin, and the icon is in /usr/share/pixmaps), so it makes package
>> management easier (to delete an application, just delete the .app
>> file -- don't need to look in /usr/share/pixmaps for the icon and
>> delete it).

> The key difference here is that Mac OS X does all of the bundle mess
> in userspace where it belongs. :-D (I know, I use it daily)

Yes.  It's handled by NSWorkspace which is approximately equivalent to
this sort of thing being handled by GnomeVFS or the KDE equivalent.  Of
course the problem with handling it in userspace is that behaviour isn't
uniform -- applications that don't use NSWorkspace (e.g. some
command-line utils, programs ported over from UNIX, etc.) won't have the
same behaviour.  Whether or not that is an actual problem seems to be
debatable.  (I don't use MacOS X, but I've done some programming in
GNUstep.)

Another problem is that it only works with bundle files.  e.g. I can't
add an icon to a regular txt file.  Tiger now supports xattrs, which you
could use for that functionality, but then we run into the problem again
of not being able to edit it with regular applications.

> I think that part of Reiser4 needs more review than it's been given at
> present.

Looking forward to the flamewar that happens when Namesys decides that
file-as-dir is ready to be turned on again. ;-)

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/