Public constructors for Request and Reply types

[asomers]

It would be nice to be able to unit test my filesystem's FUSE interface. Right now the only way to test it is to mount an actual filesystem and use the command line. But if rust-fuse did the following, then I would be able to write tests that hook into my filesystem's rust-fuse interface and exercise the whole API. This would require:

• Public constructor (possibly Default for Request)
• Public constructors for all the various Reply types.
• Public accessors for the various Reply types, for example to see the data stored by ReplyData::data.

[chisa0a]

So much this.

Trying to use rust-fuse as a library crate is all but impossible atm. Would this be a better suited task for implementing a high-level API?

New to the library, and to Rust, and would really love to use rust-fuse in a project. Happy to contribute where I can.

Many thanks in advance.

[zargony]

Back then when rust-fuse was created, we intentionally chose to have no public constructors to ensure that implementations comply with what the kernel protocol requires. Nowadays the interface on the Rust side still works the same but looks a bit unusual. There's ongoing effort (e.g. in #90 and the modernize branch) to make rust-fuse more idiomatic and especially add async and testing capability. I suppose that request and reply types will completely change so that this issue won't apply anymore. But afaik there is no issue specific to testability yet, so if you edit this issue to be more generic towards the new implementation, we could use it for collecting ideas and tracking progress of making fuse implementation testing easier.

[asomers]

I've been working on a new approach to testing crates that use rust-fuse. I'm using mockall to create mock versions of each Request and Reply type. Then I have to redefine FileSystem to take these mock types instead of the real ones. It's a lot of boilerplate, but it seems to work.