Major refactoring => v0.5.0

[Alogani]

For v0.5.0

• Get rid of macros and replacing using jinja templates
  • For FuseDriver
    • Types
    • Methods (+merging)
  • For FuseHandler

=> MERGED with #81

• BREAKING Don't have a unique FuseHandler/FuseDriver conditionnied by compile features, but instead split each of them inside src/fuse_parallel, src/fuse_serial, etc
• BREAKING custom signatures for mount / spawn_mount depending on mode
• BREAKING remove inner: Box<dyn FuseHandler<T>>
• implement a first working async FuseHandler
• Update src/templates
  • Renaming to src/fuse_presets
  • Adding eventually both MirrorFsPreset (implement what is necessary, doesn't inherit FuseHandler) and MirrorFs { default_fs } ? => easier to jump start tests, but is it really useful ?
• Update tests
• Update examples
• BREAKING change signature of spawn_mount / mount Options to let the user define num_threads, executor_threads, reply_threads + defaulting to core count
• verify and update docs

To follow short term after release :

• Isolate complex DirMapIter struct (in FuseDriver) and add better testing
• More debug!()
• Tackle bug I/O Error following CD to non-existing subdirectory #55
• Look at PR issue #55 #83 to see why the initial code tried to do an open instead of a lookup

To follow long term after release :

• Move src/core/inode_mapping.rs, src/inode_mapper, src/inode_multi_mapper inside src/inode_mapping/
• Improve performance of FuseDriver in serial by avoiding unnecessary cloning
• Move code of some examples inside src/fuse_presets if appropriate
• Modify unix_fs to rely on async io if possible

[khanhtranngoccva]

Hey there @Alogani,

I am slightly curious about why the rationale of opting for a templating engine like MiniJinja. Technically, it is worse than macros, since code completion do not work properly on a Jinja template. Additionally, the async module probably requires a separate implementation on its own.

[Alogani]

Hey there @khanhtranngoccva,

• Code completion works fine : because jinja are transpiled to rust code and then with include it is catched by rust--analyzer. I have to restart rust-analyzer after the changes made to the jinja template, but apart that, it works
• We can make syntax highlighting work too more or less : a11ca59
• macros code produced is not directly visible (we can use rust-analyzer expand feature though), whereas jinja builded code is directly visible in OUT_DIR. It is still annoying but i find it a bit easier to look at it
• My first attempt with macros used an ugly DSL where i put keywords that would be replaced by codes like : $handle_reply { reply.ok() }. Using my own DSL is far less maintanable and readable, whereas jinja syntax is very powerful and well known
• Because it is powerful, it would allow to create the separate async implementation while still reusing portion of other parts of the code. Avoiding duplication is a main goal

This is not shiny, but when looking at code in _big_refactor2 branch (macro based) and devel branch (jinja), i find it a win.

Although i still intend to use macros for everything that looks like a "Fuse template". For example :

struct TestFs {
    mirror_fs: MirrorFs, // MirrorFs already implements its own functions but doesn't inherit FuseHandler trait
}

impl FuseHandler<PathBuf> for TestFs {
    delegate_fs!(mirror_fs, ["write"])
    /* Equivalent to
    fn write(&self, req: &RequestInfo, file_id: TId, file_handle: BorrowedFileHandle, seek: SeekFrom, data: Vec<u8>,
        write_flags: FUSEWriteFlags, flags: OpenFlags, lock_owner: Option<u64>,) -> FuseResult<u32> {
        self.#mirror_fs.write(...)
    }
     */
}

This is still work in progress and my mind is not set on details.