Hi, ----- Mail original ----- > De: "Sebastian Kügler" <se...@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 <<
