Intro

Here are things that I'd like to cleanup going forward. Since this has ramifications on all existing projects using FluentFTP, and since these will be major breaking changes to the API, I'd like community feedback on these changes so that they are not hasty, disruptive, or out-of-touch with the actual userbase.

I would like these to be part of the v40 release so its easy for existing users to understand that v39 is the "legacy API" and that v40+ will use the "newer API". I have never undertaken such a large systematic refactoring before.

Topic 1

• Problem: We have a lot of old/weird/unused functionality that is probably broken or not well tested or not being used.
  • EnableThreadSafeDataConnections - Crazy feature which spawns new FTP connections for each file transferred
  • QuickTransferLimit - Implemented but disabled
  • FtpClient.Connect(Uri) - Static constructors
  • FtpClient.GetPublicIP() - Static methods
  • DereferenceLink - does anyone even use this?
  • 200 different constructors for FtpClient - I would just like 1 or 2 constructors for common patterns.
• Solution: Drop these features entirely.

Topic 2

• Problem: We have a massive set of properties directly within the FtpClient class which clutters up its API.
• Solution: Store all configuration setting properties into child classes whose references are stored within the FtpClient. This groups up the properties into logical categories and also eliminates them from the FtpClient API.
  • client.Connect() becomes client.Connect(FtpProfile)
  • client.FXPProgressInterval becomes client.FXP.ProgressInterval
  • client.DownloadZeroByteFiles becomes client.Download.ZeroByteFiles
  • client.TransferChunkSize becomes client.Download.ChunkSize and client.Upload.ChunkSize

Topic 3

• Problem: Most FTP servers don't support directly downloading/uploading from an absolute path (eg: /root/animals/duck.txt, therefore we should always set the working directory to the folder (eg: /root/animals/) and then download the file (duck.txt). And we should not allow the user to manually modify the working directory because it would conflict with this system.
• Solution: Drop support for GetWorkingDirectory and SetWorkingDirectory and instead always automatically set the working directory before file transfers or even getting the file size, etc. This would even fix issues where there are spaces in directory paths, and many other things. It would put us in parity with FileZilla.

Topic 4

• Problem: Our logging is a mess. We should be able to integrate with NLog and other standard .NET loggers.
• Solution: Drop support for FtpTrace and its outdated API and instead support a client.Logger property which can be set to our default logger or an NLog instance, etc.

Topic 5

• Problem: Poor implementation of timezone conversion. Fixed implementation that does not allow users to customize it.
• Solution: Implement a strategy pattern so users can select from:
  • NoTimeConversion
  • TimeZoneConversion - a new method that allows for DST to be observed (missing feature)
  • TimeOffsetConversion - users specify which is their PC timezone and the server timezone and we do simple math to convert it (current method)

Topic 6

• Problem: We have 2 implementations of each function, a synchronous version and an async version. This causes bloat, mistakes/mismatches in the implementation, and weird behavior.
• Solution: Drop support for synchronous API. Drop support for <.NET 3.5 as it doesn't support async.

Topic 7

• Problem: Too much bloat with older IAsyncResult style async functions.
• Solution: Remove it. Anyone who wants async can just use async/await.

Lets talk!

Please start the discussions below! Add your comments and mention which topic you are talking about. You can comment on any topic(s) that you like.