Work is in full swing on the new file system implementation of fman. It will make it possible to implement ZIP file support, (S)FTP, etc. Best of all, it will allow you to add support for your own file systems via fman's scriptable plugin system. Until the new implementation is ready, I thought I'd update an item on the web site that has been on the back of my find for a while.
The Zen of fman is an opinionated list of principles that guide the file manager's design:
Extending must be easy.
Customisability is important.
But not at the expense of speed.
I/O is better asynchronous.
Updates should be transparent and continuous.
Development speed matters more than program size.
The last item
Development speed matters more than program size
holds true of fman, but has never quite been as "on-point" as the others. I've decided to replace it by:
Don't reinvent the wheel.
In a way, this principle encompasses the previous version. It says to use an existing solution if it exists. Such a solution usually includes more functionality than needed, thus unnecessarily increasing fman's program size. But at the same time, not having to create it from scratch saves a lot of development time.
(An argument could be made that static linking lets you have the best of both worlds by only including those parts of a library that are actually used. But fman is based on the Python programming language where that is less of an option.)
The benefit of the new principle is that it explains more decisions behind fman. For example, some other file managers have a built-in terminal, a built-in text editor, file viewer, music player, etc. Some users really like the "integrated feel" of such solutions. My gripe with them is that I could spend years programming a built-in terminal or a file viewer, and they would still never be as good as tools that have been on the market for many years. I think it's much more important to focus my efforts in those areas where fman is truly able to excel. Like scriptable file system support!