I was worried, because I'm currently working on a tagging system and they beat me to the release, punchy website included.
Then I realised that they built it on top of FUSE, and SQL, and took a sigh of relief.
((EDIT: Perhaps this is a little harsh? I didn't mean to be harsh, just precise, but perhaps I went a little over the top -- I apologize to the authors if I did.))
I investigated the FUSE/db option earlier a year or two ago, and personally I don't see this as an interesting or compelling solution to the file<->tag problem. Because users move and rename files, pathnames are potentially semantically meaningless to the tag system. The contents of files change often, and arbitrarily (given things like MS Word's formats which are literal memory dumps of what word is doing, not to factor in encrypted files, etc.), because of this, file hashes are potentially semantically meaningless to the tag system.
In other words, basic file operations (reading/writing/renaming) will cause this system to break your tags without significant work to keep the file<->tag relation consistent. You can attempt to mitigate this problem through systems that keep track of files (inotify, etc.) but that introduces a runtime cost and has technical difficulties as well. It's 'designed' (albeit unintentionally) to break from the start, and the developer has to exert a large amount of effort to stop the system from breaking. To me it didn't seem like the effort was worth it, that the innate flaws were not worth surmounting. Unfortunately to avoid this from being a 'debbie downer' post, I'd have to talk about the alternative approach, which I don't really have space (or the time, right now) to do here.
It sounds like this is a pretty easy problem to solve if files aren't identified by their names. If a file just has a name (and a parent, and a bunch of tags...) then tags are trivially stable when moves/renames/writes happen. No need to hash anything, ids are a fine way to track identity, and perfectly amenable to storing an a SQL database.
If you want to support hard links you can decide whether to associate tags with files or inodes, depending on whether you want all linked files to have the same set of tags.
> It sounds like this is a pretty easy problem to solve if files aren't identified by their names.
That would make things slightly better, but it's really not how things are supposed to look from userspace. You still have the problem of tags not being preserved across file copies, and not across filesystem boundaries (Which, the latter is almost a universal problem in this space, I guess).
User space shouldn't care about implementation details like storage primary keys. I don't think copies are difficult either, but I guess some other storage scheme could make them simpler.
In short: when it's ready. I struggled with some health stuff last year which led to a delay (and also got side-tracked with some other projects that went nowhere). At the moment I'm satisfied the core library (libkoios -- koios being the greek word for 'to query' c:) works but I don't really trust myself not to have forgotten something.
At the moment the program's interface has been worked through, the documentation written up, and I'm just plugging the user-level interface together, so maybe a few days to a week to run through everything. I'm still not comfortable with my application-level testing either so we'll see I guess.
It's going to be free software, yeah. I think it's nice to have something to work towards, and it allows myself to be messy with the project or start over without having any ties. At the same time, I do generally believe that software should at some point be Finished (aside from compatibilty updates and maybe one or two ease of life features), so I have the aim of crushing all or most of the bugs I encounter before releasing to the public, even though the public release is technically 0.0 :)
I guess a fun way of saying it would be, software is an artisanal craft so out of respect for what I'm building and for the users, I don't really want them to see something that is obviously imperfect, until I've smoothed those over.
The less fun way is that I don't want the responsibility of someone running it in production, then for things to go belly-up, haha
Please make a Show HN post or something similar when you feel your work is ready to share; I have a feeling that there are a ton of us around here who would be super interested in checking it out!
Then I realised that they built it on top of FUSE, and SQL, and took a sigh of relief.
((EDIT: Perhaps this is a little harsh? I didn't mean to be harsh, just precise, but perhaps I went a little over the top -- I apologize to the authors if I did.))
I investigated the FUSE/db option earlier a year or two ago, and personally I don't see this as an interesting or compelling solution to the file<->tag problem. Because users move and rename files, pathnames are potentially semantically meaningless to the tag system. The contents of files change often, and arbitrarily (given things like MS Word's formats which are literal memory dumps of what word is doing, not to factor in encrypted files, etc.), because of this, file hashes are potentially semantically meaningless to the tag system.
In other words, basic file operations (reading/writing/renaming) will cause this system to break your tags without significant work to keep the file<->tag relation consistent. You can attempt to mitigate this problem through systems that keep track of files (inotify, etc.) but that introduces a runtime cost and has technical difficulties as well. It's 'designed' (albeit unintentionally) to break from the start, and the developer has to exert a large amount of effort to stop the system from breaking. To me it didn't seem like the effort was worth it, that the innate flaws were not worth surmounting. Unfortunately to avoid this from being a 'debbie downer' post, I'd have to talk about the alternative approach, which I don't really have space (or the time, right now) to do here.