[Feature Request] - Better composability

[JohnScience]

Description

As I was working on a commercial project using suppaftp, I faced various challenges:

• lack of support for Drop on ftp- and data- streams,
• lack of Send, which is a WIP`,
• lack of integration with serde,
• lack of support for implementing retry logic in case of connectivity issues,
• private visibility of important traits, notably TlsStream,
• rigidity of the APIs, notably ImplFtpStream::list returns a FtpResult<Vec<String>> instead of an iterator over results,
• lack of an iterator over std::list::File on a remote server,
• lack of RemotePathBuf and RemotePath (though it goes beyond the scope of your crate),
• lack of a canonical method for file synchronization (think of comparing the state of the remote server against an "index" and applying changes to the local replica of the file hierarchy).

Thanks to your crate, I was spared from a lot of work, so I thank you for that. However, the library right now is fairly low level and does not offer many conveniences that one could expect.

For now, my biggest annoyance is the ImplFtpStream::list method, which probably shouldn't have existed in this form.

When implementing an iterator over remote entries, I have to deal with a Vec<Vec<Result<MyCustomDirEntryType, MyCustomWrapperAroundParseError>>.

And due to the nature of the iterator, I ended up facing the limitations of the NLL borrow checker (danielhenrymantilla/polonius-the-crab.rs#11) and I had to deal with the absence of entry API on vector until the pain became so severe that I ended up implementing entry API for Vec as a stack (link).

Without your library, I would have to write FTP client code myself, so again, thank you.

Changes

The most important changes are the following:

• Add a method on FTP streams that returns an iterator over results to allow users to choose the container.
• Add a feature that would enable serialization and deserialization of suppaftp::list::File, suppaftp::list::ParseError, and suppaftp::types::FtpError.

[JohnScience]

Regarding Drop, I realize that it's fallible, so it could be your motivation. However, presenting a way to do that with reasonable defaults would be awesome. If you want to have a fallible drop in Rust, you can consider sharing your opinion/thoughts in https://internals.rust-lang.org/t/idea-fallible-drop-attribute-for-let-statements/19680.

[veeso]

That's a very interesting feedback. I will check every point to see if it's feasible.

[JohnScience]

@veeso

I seem to have managed to come up with an idea on how to write an iterator despite the limitations of the pre-Polonius NLL borrow checker: https://github.com/JohnScience/list_iter.

Note: it is implemented for MockFtpClient, which requires fds instead of paths. Managing paths adds only a little bit of complexity. Dealing with Results adds moderate amount of complexity.