lkml.org 
[lkml]   [2005]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: reiser4 plugins
    From
    Date
    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/

    \
     
     \ /
      Last update: 2005-06-28 19:56    [W:4.359 / U:0.076 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site