[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Nepomuk in 4.13 and beyond
From:       François_K. <daitheflu () free ! fr>
Date:       2013-12-19 17:35:50
Message-ID: 1845256719.262220910.1387474550751.JavaMail.root () zimbra76-e14 ! priv ! proxad ! net
[Download RAW message or body]

Hi,

----- Mail original -----
> De: "Sebastian Kügler" <sebas@kde.org>
> À: kde-devel@kde.org
> Envoyé: Jeudi 19 Décembre 2013 16:16:32
> Objet: Re: Nepomuk in 4.13 and beyond

> > > * What are the plans to store tags ? On OSX, tags are stored in
> > > files
> > > xattrs which is -IMHO- very nice : - Metadata live and die with
> > > the file
> > > ;>
> > > - No "store" query when you move or copy a file ;
> > > - You don't rely on a "store" to tag files ;
> > > - You also don't end with a huge store full of unuseful things
> > > like it
> > > 
> > > used to happen with Nepomuk some time ago (no offense) ; - You
> > > can easily
> > > backup the metadata (at least files metadata) : you just have to
> > > use a
> > > decent backup tool that handles xattrs ; - It's CLI-friendly ;
> > > 
> > > - ...
> > 
> > +1
> > 
> > I'm leaning towards this as well.
> 
> To my knowledge, the list of filesystems with proper xattr support is
> rather
> short. This means, a fallback mechanism is needed, at which time one
> has to
> ask if the primary mechanism is really needed. Programs like "cp"
> don't seem
> to consider xattr by default, so the "CLI" friendly is limited to "if
> you
> remember to copy xattr" as well.
> 
> The advantages of xattr are quite limited due to this, it's
> definitely not a
> silver bullet.

According to Wikipedia :
http://en.wikipedia.org/wiki/Extended_Attributes

But, yes, clearly, I don't know if those FS **properly** handle xattrs. We should \
probably get some input from an FS expert before seriously considering this option. \
This was just an idea that I found interesting. We have this thing that exists for \
quite some time now and I thought it would be easier to just benefit from it instead \
of re-inventing the wheel :)

Also note that this would also mean that we need a >=2.6-with-xattr-enabled-Kernel.


It's always the same issue : where do we want to place the cursor between "supporting \
old technologies" and "stepping into the future" ?

Cheers,

-- 
François

> > Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]