## Switch storage format
Switch the storage format to something that can make use of the FTP `APPE` command.

Pros:

 * Only upload what you need (almost zero overhead)
 * Combinable with #1

Cons:

 * Most code will have to rewritten
 * You can only log changes to the end of a file (leaving the original data intact)
 * If you have many changes the file will blow up tremendously and will require frequent trimming of unused data
 * Other clients will have to download the entire thing every time something changes<br />(no change from current situation)

## Switch storage format (with extra index file)
Switch the storage format to something that can make use of the FTP `APPE` command. Additionally write an index file that contains the binary offset and length of each data block. Clients can then download only the parts they need using `REST` and `RETR` commands.

Pros:

 * Only upload what you need plus the index file
 * Combinable with #1
 * Other clients only have to download what they need

Cons:

 * Most code will have to rewritten
 * Index file has the updated every time
 * Might not be possible in your case<br />(if there is no way to identify the files content by name)
 * You can still only log changes at the end of the main file (leaving the original data intact)
 * If you have many changes the main file will still blow up tremendously and will require frequent trimming of unused data