> might be nice to have on exclusively one-user, isolated machines, like
> "keep /my/ annotations/icon/application name/whatever with the file's
> data", but that break down in multiuser (even serially, one user after the
If this is really the core of your (and the rest of the reiser-
obstructionist crowd's) objection to the file-as-directory concept, then
you just haven't thought it through thoroughly enough. Ignore for the
moment the case of system-wide or network-wide shared data, and think
about it just limited to a user's home directory, and the storage and
organization of actual *data* (as opposed to system files). The desire
amongst users for ubiquitous metadata is very real - the current wave of
"desktop search" products and technologies demonstrates this - but
search is really only the lowest-hanging fruit of this new way of
looking at data. Application-layer solutions like Beagle, Google Desktop
Search et al allow for querying on metadata, but actually *acting* on
the results of those queries requires that they be exposed via first
class primitives which can be manipulated with arbitrary tools, not via
some proprietary userland api which only one tool ever actually
implements.
As to the case of system-wide shared files, there is already a mechanism
to prevent users from inappropriately annotating files that don't belong
to them: file permissions. If you're sysadmining a multiuser reiser4
box, and your users are able to modify the metadata of files they don't
own, then you go to sysadmin purgatory.
> other way; OpenOffice /has/ structured files, XML inside zipped files,
Java
> also uses zip files for its structuring needs, etc), or are ideas that
And as a Java developer, I can tell you that the wide consensus is that
this solution is half-assed and insufficient for both developers and
users needs. In fact, I believe there is currently a JSR in progress to
develop a more sophisticated Java packaging model.
--
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
