ViBiOh
Tagging, virtual but persistent (query/search -based) directories to share with others
I wonder if there is any easy (even if it includes writing a few lines of Go and subsequent recompilation, I consider it easy :wink:) way to allow users with proper rights to "tag" any files (incl. photos & videos) to allow for "generate share link from a search query consisting of this set of tags".
If one has too many files, then sharing with (multiple) others is not any more a hierarchical problem (not 1:many mapping) and thus needs many:many mapping. Therefore I seek something like tagging.
And by tagging I do not mean anything advanced (no DB of tags, no "management of tags" themself, nor anything similar). But just "associate this arbitrary string with this file" (if we had only image files, we could add it to EXIF or similar container; but I would prefer if tagging was not filetype-specific and thus EXIF is not the way to go).
And then "list only files having this set of tags" functionality (including negations "list only files having this set of tags while not having any from this other set of tags" and case insensitive substring matching by default). And persist such queries as "virtual" folders. Then we can share such lists in the same way as regular folders are being shared now.
Any pointers?
Of course, the best would be to have this functionality built-in :wink:.
Hi @dumblob,
Thank you for your suggestion, seems like a valid way.
I think we can store the tags' list in the EXIF file, which is more a metadata file and currently exclusive to media type. For example, the description on the story mode goes into this file (but the story mode is only relevant for image with thumbnails).
I think there is no blocker to add more fields. I need to unlock the feature for all kind of file (and have a look in term of performance).
The second part is more complex. Virtual folder or "search result folder" and share them, currently it's not designed to perform it. Maybe longer to implement.
The second part is more complex. Virtual folder or "search result folder" and share them, currently it's not designed to perform it. Maybe longer to implement.
Ah, good to know. So if I understand correctly, there is so far no "search" engine in fibr and thus this all has to be introduced, right?
There is a search feature, based on criteria. But when listing files and folders, I will also need to add "virtual folders" stored elsewhere to that list.
It's not an engine with storage, every time you ask, no cache, it asks to the underlying filesystem.
Hm, thinking about this - if this tagging + virtual folder functionality would be accepted in upstream (by you :wink:), wouldn't it be easier implementation-wise to actually make all folders virtual?
Real folders would simply have a non-removable default tag real_folder:/the/original/full/path (eh, bad naming, but you got the idea).
Or something along these lines instead of having "two mechanisms with similar APIs" co-exist?
Performance should not be a problem as for these default/built-in immutable tags there could be heuristics and other built-in optimizations instead of a generic query processing.
It's not an engine with storage, every time you ask, no cache, it asks to the underlying filesystem.
That's a good thing!
Following on this, I added (a while ago) the tagging on each file and the ability to search by tag, and store the search result as a folder. Is it what you expected?
As always, no index, so if you search on a large folder, it can be a bit slow.