Relates to #52

Have the possibility to tell the sdk that a file is completely uploaded.

The method exists, yet it is hidden behind a private interface.

Shamefully, we're not massively well documented. We should change that. We can use YARD to implement the docs we need.

One thing I think is an underrated feature of this API (and indeed WeTransfer itself) is the ability to put content in the title and message fields of a transfer. This has a lot of possibilities:

• slightly ephemeral link based messages (with lovely WeTransfer art in the background)
• some kind of one-time-pad encrypted message solution?
• narrative experiment combining attached files and text in the message field
• ???

Feel free to tackle this issue however you'd like - if you've got an idea for an example project, make the thing and let us know if we can help :-) - but this is also a good space for discussion and bouncing ideas off each other.

When uploading files, it's nice to have a progress callback every time a chunk has been uploaded. This should be optional (not all users will want to have this cluttering up their logs) but for testing or if you're making a CLI it's a definite quality of life improvement.

Would also help bring us into parity with the JS SDK, for when this is implemented.

Through the API we allow the user to create blank transfers by issuing a create transfer request without the items hash in the body. In the current state of the SDK we do not support this functionality. We should add it! :)

We only expose the "name" field for file creation, but there's also local_identifier. While the built in SecureRandom.uuid generator will do for most use, some users may want to use a local identifier relevant to their own file system. (This is perhaps not as urgent with the current functionality of the API, but may become so in the future.)

N.B.: local_identifiers are hard-limited to 36 characters or less.

At the moment we use the client object to add items to a board or transfer (here we'll use a board as an example):

@client = WeTransfer::Client.new(api_key: "foo")
board = @client.create_board( ... )
@client.add_items(board: board)  do |builder|
  builder.add_file(name: File.basename(__FILE__), io: File.open(__FILE__, 'rb'))
  builder.add_file_at(path: fixtures_dir + 'Japan-01.jpg')
  builder.add_web_url(url: 'http://www.google.com', title: 'google')
end

or file uploads but we should make the transfer or board responsible for file upload, not the client.

@client = WeTransfer::Client.new(api_key: "foo")
board = @client.create_board( ... )
board.add_items do |builder| 
  builder.add_file(name: File.basename(__FILE__), io: File.open(__FILE__, 'rb'))
  builder.add_file_at(path: fixtures_dir + 'Japan-01.jpg')
  builder.add_web_url(url: 'http://www.google.com', title: 'google')
end

Please note that there are tests that are skipped because we don't want the original behaviour -- you should change and then implement -- search for the string "this interface is still experimental" to see them.

Relates to #52

Have a method to create a transfer and have it return an identifier.

Using that identifier, other specific methods can call actions on that transfer,

One of the things that I think could be really fun is to create a system for tying transfers to a specific location. An example project (or even a separate gem/app/???) that creates a transfer connected to a set of coordinates or a physical space would be awesome to have, and it'd be amazing to see what people build with it / on it / around it.

Right now we don't have a DELETE endpoint available, or a method for limiting the number of downloads - but even something that works with a system like the venerable geocoder could get things started.

Feel free to tackle this issue however you'd like - if you've got an idea for an example project, make the thing and let us know if we can help :-) - but this is also a good space for discussion and bouncing ideas off each other.

No matter what the media says, twitter bots are extremely good. Projects like soft landscapes, literally anything by Darius Kazemi, the lovely and interactive Rijks Bot and so on and so forth make Twitter a much more fun place to be. So we should definitely have a starter kit for a bot that (somehow) combines the WeTransfer API with Tweets.

We need something basic but extendable we can put in the /examples directory for people to build off of, though if you'd like to create your own implementation be our guest! :) I highly recommend using the lovely twitter gem for handling the interaction with the Twitter API.

Feel free to tackle this issue however you'd like - if you've got an idea for an example project, make the thing and let us know if we can help :-) - but this is also a good space for discussion and bouncing ideas off each other.

Give the end user more control over the uploading flow (adding files, completing uploads, finalizing transfers)

Is your feature request related to a problem? Please describe.
We now support adding link items via the API. See the docs here. We should add this capability to the SDK!

Instantiate Faraday just once

Make sure to re-use objects if they allow it.

In order to make adoption as easy as possible, it would make sense to have the simplest use case available to tramsfer using the ruby sdk

The steps involved could be

1. create upload client
   • add all files to the transfer
2. tell the client to finish the transfer (in its own time)
3. the API returns the url that eventually holds the completed transfet

When this is moved to open source we can add it to travis-ci.org for automated testing goodness.

Currently, the complete_file! method lives on a WeTransfer::Client instance.

The low level responsibility for signaling that the file is complete should not be on a high object that the client is, but it should be moved to the file (RemoteFile) itself.

Is your feature request related to a problem? Please describe.
In the near future, the API allows deleting files and links of a board. The Ruby SDK should be able to handle that as well

Describe the solution you'd like

Describe alternatives you've considered

Additional context

See related issue: WeTransfer/wt-api-docs#96

Currently, the SDK allows me to either do everything at once, or not at all.

I want to be able to just

• create_transfer that just creates a transfer
• call upload_complete for a specific file
• requesting a part_number for a specific chunk of a file
• finalize a transfer

At the moment we have one majestic suite of integration tests. Help us out by implementing unit tests! One potentially interesting thing here is that the integration tests rely on actual API calls - but doing real-live-calls for every test suite run is less than ideal. If you love test mocks this is the issue for you! (Or maybe you've got some other solution you'd like to add?)

Relates to #52

In order to upload a specific chunk of a file, it would be helpful if the SDK would allow me to do just that

SDK V2

Appraoch on the V2 of the SDK

We're going to add Board end-points to the API, also the 'old' transfer end-point is changing slightly. That's why I write this RFC to discuss implementation.

Boards

We've added the boards end-point, that means you now have two options to share items.

Board's work in a more collective way, so you first create a empty board:

new_board = WeTransferClient.create_board(name: 'title', description: 'description')

To which you later can add files to with add_files and add links with add_links:

WeTransferClient.add_files(board: new_board) do |b|
  b.add_file_at(path: '/path/to/another/local/file.jpg')
  b.add_file(name: 'README.txt', io: StringIO.new("This is the contents of the file"))
end

WeTransferClient.add_links(board: [Object]) do |b|
  b.add_link(url: "https://www.the.url.you.want.to.share.com", title: "title of the url"))
end

To complete the process the following methods are needed:

• requesting upload urls per chunk: WeTransferClient.request_upload_url(board_id: [String],file_id: [String],part_number: [Integer])
• uploading files: WeTransferClient.upload_file(upload_url: [String] ,file_io: [File])
• completig files: `WeTransferClient.complete_file(board_id: [Integer] ,file_id: [Integer] )

And for the GET endpoint we use: WeTransferClient.get_board(board_id: [String])

Transfers

For the transfers the flow will be:

Creating a Transfer and add files directly

transfer = WeTransferClient.create_transfer(name: [String] ,description: [String]) do |b|
  b.add_file_at(path: '/path/to/another/local/file.jpg')
  b.add_file(name: 'README.txt', io: StringIO.new("This is the contents of the file"))
end

The folowing methods will be needed to complete the process:

• Request upload_url per file: WeTransferClient.request_upload_url(transfer_id: [String],file_id: [String] ,part_number: [Integer])
• Upload file: WeTransferClient.upload_file(upload_url: [String] ,file_io: [File])
• Complete file: WeTransferClient.complete_file(transfer_id: [String] ,file_id: [String] )
• Complete transfer WeTransferClient.complete_transfer(transfer_id: [String])

And for the GET request it will be: WeTransferClient.get_transfer(transfer: [String])

Describe the bug
We select files on their name, but we should also sanitize the names to prevent odd errors from the Transfer / Board endpoints

WeTransfer backend systems sanitize emojis (and control characters and special fs characters) from a file name. The sdk should do that as well, to bring that behavior closer to the end user, and have less surprises.

Expected behavior
We should sanitize the filenames and remove all characters that are lager then 4 bytes to prevent unforeseen errors with the Transfer endpoint

Possible Solution
filename.each_char.select{|c| c.bytes.count < 4 }.join('')

This is made much easier by #14 -- but essentially it is possible to add items to a transfer after the initial create step - even if you've added items to it already. This is a unique feature of our mobile app and the API. From a usability standpoint this is only possible for now if you store the transfer id generated when the transfer is created somewhere, though in the future we'll add GET functionality to the API and make your life much easier.

Here though the thing we need is a method that takes a transfer id and goes through the upload flow to add items to it.

relates to #52

A transfer that has had all its files (chunks) uploaded and completed can be finalized.
This method should become a public one.