Re: reiser4 plugins

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Horst von Brand wrote:
Kevin Bowen <[email protected]> wrote:

[...]

                                                           The desire
amongst users for ubiquitous metadata is very real - the current wave of
"desktop search" products and technologies demonstrates this -


Just like each previous claim "this /must/ be the next cool technology!",
also called later the "dotcom crash"...

Have you used this technology?

For that matter, some of these claims have been true. The Internet, despite the dotcom crash, is now a requirement -- few people would use an OS with no networking support on a desktop PC. Same goes for GUIs. Both of these technologies had to have at least some amount of kernel support, both were once weird and experimental, and both are now in demand by users and likely to be for some time.

If we're right, and searching is the next best thing, then it would be a good idea to get started now. If we're wrong, what's the harm?

(Assuming /meta, of course. I accept that the issues with file-as-directory may never be solved to the point where we can do it at the kernel's FS/VFS level.)

                                                         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.


Could you please explain in plain english? The only part I get out is
"propietary API", and I don't see anybody advocating such here.

I don't understand it much, but I think the point being made is that while desktop searches may be able to search metadata (not sure how they do this -- their own plugins or just full-text searching?), they cannot write to said metadata. To change metadata on a file, one currently needs to use a proprietary userland api which is only implemented by one tool.

So, for instance, if I want to grab all mp3s with Artist "Paul Oakenfold" and change the genre to "techno" (can you do that?), I can use Beagle's search tool to find all mp3s by Oakenfold, but to change the genre, I have to use some separate tool to manipulate id3 tags, which may or may not exist in an easily scriptable form.

I know there's a decent tool for id3 tags, but there's so many kinds of metadata and so many tools out there that the user can't possibly memorize them all. This is why I use the zipfile example, despite its flaws.

Now, the "arbitrary tools" bit is about how one could do this kind of thing with file-as-dir or /meta. With file-as-dir, it might be as simple as:

$ for i in `magical-find-tool artist='Paul Oakenfold'`; do echo 'techno' > "$i/.../genre"; done

Or even

$ echo 'techno' > /.../search/artist='Paul Oakenfold'/*/.../genre

It doesn't get too much more complicated for /meta, which has a nice side effect of not killing things like tar and generally not messing with POSIX.

One could also use vim, emacs, or whatever else to edit this metadata, instead of being limited to one program. This is especially nice considering you might have to look up which one program to use.

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.


And who says that a normal user isn't allowed to annotate each and every
file with its purpose or something else? I can very well imagine a system
in which users (say students in a Linux class) want to do so... on a shared
machine. Or users having a shared MP3 or photograph or ... collection, with
individual notes on each. Or even developers wanting to annotate source
code files with their comments, but leave them read-only (or have them
under SCM).

File-as-dir is actually pretty nice for this, I think. Since the annotations appear as files, if the app supports it, the users can each store individual annotations, world-readable, but only user-writable.

With something like Gnome-VFS, I doubt there's even a mechanism whereby such annotations can be shared to begin with.

But this is just a thought experiment atm, don't pick it apart too brutally...
-
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]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux