Andrea Galbiati

Hi, ### Foreword as I already suggested in other issues, I would try, whenever possible, to avoid behaviour by enums, favoring a strategy pattern instead. This would have the benefit...

I'm not expert on FluentFTP client internals, so I'm still talking in a very theoretical way, based mainly on the _Find What Is Varying and Encapsulate It_ basic principle. So...

This may be silly or very naif. What about adding sync stuff as ExtensionMethods? That would allow keeping the class basically sync, users would be happy as they can call...

> No, that would not solve the main problem of duplicating code. Ok but then this is why > I don't know why users can't just create a background worker/thread...

I would probably drop the `FtpTraceLevel` way to go, I was thinking more to something like this ```cs public interface IFtpLogger { void Trace(string message); // I personally see no...

> We already have implemented a [server-specific strategy system](https://github.com/robinrodricks/FluentFTP/wiki/Custom-Servers) which implements this as [far as possible](https://github.com/robinrodricks/FluentFTP/tree/master/FluentFTP/Servers/Handlers). Some zOS specific code is still remaining in the core which should be refactored...

> I for one need this enum I'm curious: why? I mean, on one side the lib tries to hide the server differences, on the other side it must expose...

@FanDjango it's fine, I just needed some context. Thanks

It makes perfect sense. The important thing, to me, is that the enum is not used internally for stuff like `if(serverType == xxx)`. These are my 2 cents. Cheers A

> **Usage:** To set a logger you can use `client.Logger = XYZ` and/or `client.LogToConsole = true` `Console` is a possible output, so the former includes the second. I agree with...