I use a deeply modified fork of this every day. My changes have been:
1. Rewrite the backend in Go (I'm nkt qualified to audit the C version, and having Web Stuff™ interact directly with an unaudited C filesystem daemon makes my skin crawl)
2. Modularize it quite a bit to make it easier to add endpoints like...
3. Rudimentary Tree-Style Tabs support
4. Desperately try to improve the performance enough to navigate a sizable session (I have not yet succeeded)
Even after all this, I've come to the conclusion that the relationship is backwards: the filesystem representation needs to drive the browser, not the other way around.
It's my considered opinion that some hero needs to step up and build a browser that exists to render one tab and nothing else, shelling out for everything more complex than scrolling. Then the power users cwn supply their own tab/bookmark/window/filesystem schemes using whatever glue they prefer, be it python, node, shell scripts, Windows Explorer...
1. Rewrite the backend in Go (I'm nkt qualified to audit the C version, and having Web Stuff™ interact directly with an unaudited C filesystem daemon makes my skin crawl)
2. Modularize it quite a bit to make it easier to add endpoints like...
3. Rudimentary Tree-Style Tabs support
4. Desperately try to improve the performance enough to navigate a sizable session (I have not yet succeeded)
Even after all this, I've come to the conclusion that the relationship is backwards: the filesystem representation needs to drive the browser, not the other way around.
It's my considered opinion that some hero needs to step up and build a browser that exists to render one tab and nothing else, shelling out for everything more complex than scrolling. Then the power users cwn supply their own tab/bookmark/window/filesystem schemes using whatever glue they prefer, be it python, node, shell scripts, Windows Explorer...