[_pdp_]

We have also attempted to implement exactly this but it turned out to be really bad architecture.

The file system as an abstraction is actually not that good at all beyond the basic use-cases. Imagine you need to find an email. If you grep (via fuse) you will end up opening lots of files which will result in fetches to some API and it will be slow. You can optimise this and caching works after first fetch but the method is slow. The alternative is to leverage the existing API which will be million times faster. Now you could also create some kind of special file via fuse that acts like a search but it is weird and I don't think the models will do well with something so obscure.

We went as much as implementing this idea in rust to really test it out and ultimately it was ditched because, well it sucks.

[AdieuToLogic]

> The file system as an abstraction is actually not that good at all beyond the basic use-cases. Imagine you need to find an email.

Unrelated to FUSE and MCP[1] agents, this scenario reminded me of using nmh[0] as an email client. One of the biggest reasons why nmh[0] is appealing is to script email handling, such as being able to use awk/find/grep/sed and friends.

0 - https://www.nongnu.org/nmh/

1 - https://en.wikipedia.org/wiki/Model_Context_Protocol

[skissane]

> If you grep (via fuse) you will end up opening lots of files which will result in fetches to some API and it will be slow.

This is a limitation of the POSIX filesystem interface. If there were a grep() system call, it could delegate searches to the filesystem, which could use full text indices, run them on a remote server, etc

[trollbridge]

Or maybe a file system is best used to store files and not be a general database manager.

[skissane]

The idea that there is a clean distinction between databases and file systems is very POSIX/Microsoft.

On mainframe and minicomputer operating systems they were often far less clearly separated, with a lot of functions which POSIX/Microsoft would view as belonging in a database built into the filesystem – such as record-oriented files and key-indexed files.

That's also true of MUMPS and PICK, which while nowadays language/databases which run on top of a commodity operating system, back in the day were operating systems in their own right.

Maybe some of these old ideas were just bad – or maybe we should reconsider them every now and again?

[nextaccountic]

Yep, but unfortunately this is the interface FUSE will expose

[regularfry]

A naive one, yes. You could do something a bit more interesting by having `mkdir searches/from:JoeBloggs/` or the like autopopulate in the background. I'm sure the GGP explored that though.