User: Password:
|
|
Subscribe / Log in / New account

Nepomuk: sharing application metadata

Nepomuk: sharing application metadata

Posted Nov 12, 2009 11:54 UTC (Thu) by michaeljt (subscriber, #39183)
In reply to: Nepomuk: sharing application metadata by spaetz
Parent article: Nepomuk: sharing application metadata

If my understanding is correct :) And of course, with the additional difference that the attributes are "name" "verb" "value" triples, and not just "name" "value" pairs like in my examples. Although in many cases the "verb" part will probably just be "is" or "equals".

I wonder whether Nepomuk can store this information in the filesystem for filesystems supporting extended attributes? I think BeOS did this (effectively implementing all this new stuff years ago).


(Log in to post comments)

Nepomuk: sharing application metadata

Posted Nov 12, 2009 16:36 UTC (Thu) by nix (subscriber, #2304) [Link]

Using EAs would work great *if* everything you wanted to collect data on
was certainly writable by you. It often isn't, and EAs don't have their
own timestamps: often you don't want your backup program backing
everything up again merely because an indexer iterated over it!

Nepomuk: sharing application metadata

Posted Nov 14, 2009 18:17 UTC (Sat) by Thalience (subscriber, #4217) [Link]

BeOS provided fast extended attributes on files, and optional kernel-maintained indexes on them. It has taken some time, but ext4 and other modern linux filesystems provide reasonable performance on ext attrs. The in-kernel indexer was nifty, but somewhat inflexible.

They also provided conventions for the names and formats of commonly used attributes. For example, the "length" attribute of audio files should be an integer number of seconds, not a string or a floating point number of minutes. I think that this was the most important aspect of making the feature usable on the desktop.

The combination of inotify/tracker (or nepomuk) could do all the same cool things (live queries etc), if people could agree to all use it the same way. Having one clearly defined api to support made it a no-brainer for 3rd party application developers.

The Be community was small enough that converging on a single standard wasn't difficult. The Be weekly newsletter would announce a convention, Be would release first-party apps that supported/expected it, and... done. 3rd party developers either got with the program, or users scorned them.

I turned off the indexer support on my gnome desktop once it became clear that the Nautilus developers were not interested in providing integration with it. Hope the KDE project does better.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds