Q: What is the copy performance like?
A: The application is quite a bit faster at copying files than the browser on the same machine. A bit of testing and performance tuning has been done on files of different sizes. This question has more to do with your internet connection. Downloads are almost always faster than uploads due to the way modems work. If you know you will be uploading a lot of data (e.g. going from SharePoint to SharePoint) it might be best if you use a leased (business) line, rather than home internet.
The application copies files and sets column data simultaneously, so once the application begins copying files – the operation is continuous. However, if you want to saturate your bandwidth: Have a few drag operations occur at the same time (e.g. drag & drop a few folders/files, one at a time. But, don’t have too many copy operations running. SharePoint throttles connections and will not allow many copy operations at once. That said, you can circumvent SharePoint throttling by logging in using several SharePoint accounts).
Q: Why is the file-copy time-estimated inaccurate at first?
A: It’s an estimate based on the file size(s) and how fast the upload has taken so far. The first few moments of a large copy process will likely be very inaccurate. SharePoint takes longer for the initial file creation than once the file is transferring. We could have hidden the estimate until the estimate stabilized but, we decided to display the estimate as soon as possible. It’s fun to watch.
Q: Does the application cache files?
A: No. It only caches the metadata, and only the metadata that is browsed. It is up to the user to determine which files, and where they are downloaded, through drag & drop.
Q: Does the application refresh in the background?
A: No. Requests are only made when a user does an action which requires a call to SharePoint. Otherwise, if a user just sits at his/her desk without browsing the site or hitting refresh – the application will wait, causing no internet traffic at all. This design decision has a side effect: The color status indicator will remain on the last known state. The entire application is passive and the indicator updates when the user performs an action. We were thinking of making the indicator turn to the off-line state (grey) after some amount of time, but this is confusing when the user has walked away from the computer during a file-copy. “Did the file copy?” If the indicator remains green – you can be assured the last communication with SharePoint was good. If it had turned grey – you would be unsure of the last call to SharePoint. A similar thing is true if the state was actively polling SharePoint: Maybe the file copy succeeded, then after some time the connection died, and the user came back to see red. Again, the state would be confusing. So, we decided leaving the entire application passive is a better experience, and it causes less internet traffic, to boot.
