| |||||||||||||
Plasma Active Three releasedPlasma Active Three releasedPosted Oct 16, 2012 13:39 UTC (Tue) by renox (subscriber, #23785)In reply to: Plasma Active Three released by aseigo Parent article: Plasma Active Three released
>The functional distinction between a folder name and a tag is really non-existent, except that tags have a lot of additional potential features such as: files can be in multiple tags
This isn't a very good example as with links files can be in multiple directories.
>[cut]tags can be applied to non-file data (e.g. people, or rather their contact / identity information), etc.
In a "Plan9" like organisation, everything is a file so the difference between tags and directory&links would be smaller..
I'm nitpicking, but anyway kudos for using tags! I think that this is a bold move which can be great for the users and I hope that it will succeed, I'm only a bit worried about the performance cost of using tags instead of directories (directories have already a big cost when using HDD as they "hide" the block's position on the disk: http://simula.no/research/nd/publications/Simula.ND.399/s... )
(Log in to post comments)
Plasma Active Three released Posted Oct 16, 2012 19:31 UTC (Tue) by mathstuf (subscriber, #69389) [Link]
> This isn't a very good example as with links files can be in multiple directories.
Tags are better here. Given a file with multiple links, asking "what other paths point to this inode?" is harder than "what other tags does this file have?".
Implementation detail Posted Oct 16, 2012 20:42 UTC (Tue) by renox (subscriber, #23785) [Link]
This depends only on implementation details of links..
This is not the usual way to do it, but I don't see a special difficulty in having the 'link' commands registering the source in an attribute of the destination, in which case you can answer 'what other tags does this file have?' quite easily. Another way to do it would be to have a separated database which would register such things. A find command would work too, even if the answer would be much slower.
Implementation detail Posted Oct 16, 2012 21:21 UTC (Tue) by mathstuf (subscriber, #69389) [Link]
The problem is that now `mv dir/ foo` is slow if dir/ is large. Every moved file must be checked against the database for multiple links and the new path updated. And we need foo to be fully resolved from the root of the filesystem. Alternatively, each link could be stored in the table as a (name, dirinode) pair and the path generated from the recursion over the dirinode (the mount point that the request was based in should probably be used as the "above the root" path prefix. The functionality could probably also be worked into the locate/updatedb tools.
Implementation detail Posted Oct 17, 2012 10:32 UTC (Wed) by etienne (subscriber, #25256) [Link]
> The functionality could probably also be worked into the locate/updatedb tools.
Maybe also most files in the filesystem could be tagged with the name of the rpm/deb package it comes from...
Plasma Active Three released Posted Oct 18, 2012 7:16 UTC (Thu) by spaetz (subscriber, #32870) [Link]
There is one argument in the filepath/tag debate I have hardly seen:
Yes, tags might be better and fulfil all needs that filepaths can do, but most tagging systems I know work only within the application you use.
Switch from f-spot to shotwell (or digikam), boom all information is lost. While if it's in the folder 2012/07/Boston/ I have at least some information to reconstruct where the picture was taken. This is why I don't want to give up file hierarchy based locations even if I like tagging.
|
|||||||||||||