eikek / eikek/docspell

Idea: Fuse filesystem

Open
#2,270 2 comments 0 reactions 0 assignees View on GitHub
Dominant language
Elm
Stars
2.3k
Forks
184
Avg merge
8h 2m
Merged PRs (30d)
4

Description

Just leaving this idea here so it has a place in the ether:

How about a FUSE-based filesystem that can be used to browse the DMS content? There are a number of such approaches out there already, either trying to avoid a database, or abusing the filesystem for metadata storage. But we already have a database, and an API that can be used.

The filesystem would be somewhat magic, i.e. you can `chdir()` into folders that `lsdir()` doesn't show. That way, while `/tags` only contains the set of all tags, and you can e.g. view all documents tagged `foo` in `/tags/foo`, you could also go to `/tags/foo/bar` to view all documents tagged `foo` and `bar`, and also `/tags/foo|bar` for all documents with either tag.

You could combine this with other types of metadata, e.g. `/correspondents/John` has all the files corresponding to John, and `/correspondents/John/tags:foo|bar` would give access to those of John with either tag.

Let me know if you're keen to dive further into this. Getting a beta-level FUSE filesystem written in Python isn't that hard, really…

Contributor guide

Open the contributing guide

Research direction

No files, tests, or entry points are named. Start by surveying the existing API and document metadata model, then determine the scope of a Python FUSE filesystem, including tag and correspondent paths. Done would require an agreed design, a beta implementation, and tests for the proposed path behavior.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
operating-systems
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.