Transfers

Contents

Transfers

Introduction

Various components and apps need to transfer content or files. Many of these operations take a significant amount of time. It would be nice to have a single place that the user can go to see such activity. Applications would be able to safely exit while the transfer is ongoing. Transfers may be uploads, downloads, or copy/move operations within the system.

Designers

William Jon McCann

Objectives

Display ongoing transfers
Display pending transfers
Pause/resume transfers
Allow applications to outsource responsibility for transfers
If necessary, provide notification to the user when a transfer completes
Perform a specific action when a transfer completes

Transfers may include:

Downloading application content from the web
- Photos
- Videos
- Files
- Email attachments
Downloading archives (zip, tar, etc) from the web
Person to person transfers over Chat
File copy/move operations within the system
Downloading software updates
Downloading applications to install
Uploading application content to the web
Bluetooth device transfers
Downloading purchased music, movies, etc
Backups
Downloading OS images or VMs
Storing online content for offline use

Constraints

Not a general ongoing tasks app

Relevant Art

Nokia N9

Amazon MP3 Downloader

GNOME

Firefox Downloader

Picasa Uploader

Transmission

Chrome downloads

Discussion

(from Garrett)

I've noticed that ~/Downloads becomes cluttered and eventually useless for a few reasons:

There's no easy way to rename files to names useful to *me* (and not whatever the webserver thinks is useful).
It's too hard to move the file to a useful location. (It requires opening the file manager, going to ~/Downloads, finding the file, moving the file)
Many files are downloaded to simply open up the file with another program, so ~/Downloads sometimes serves as a temporary holding space.

Possible solutions:

Enable file renaming directly in the transfers dialog
Make it easy to: (a) move the file elsewhere (reusing the file manager's "move to" dialog, when it is implemented) (b) directly import into software that handles the content (photos, music, documents, etc.), and get it out of Downloads
Consider: (a) an "archiving" function to keep the files around somewhere, but not in the ~/Downloads directory (b) an action to delete the downloaded files

This could make sense from downloading something from the Internet. It might be a little odd for file transfers, but some of it may make sense (such as renaming, importing, etc.) after file copying from a networked or USB drive, for example.

Tentative Design

Transfers Notifications

Comments

We can put Transfers in message tray. What do you think? --SvitozarCherepiy
- I think a mere notification source in the message tray is not a replacement for a standalone Transfers application, but a resident/permanent notification indicating ongoing transfers has a place in the user experience. Such notification would let the user check summary progress information, perform basic control actions (pause/resume, cancel) or launch the Transfers application (for detailed information and additional options). --AntónioFernandes
Transfers could be display next the icon of the application in the dash or maybe even next to the window in the overview. For more details see the bug
- https://bugzilla.gnome.org/show_bug.cgi?id=701402
Transfer should use a different emphase for the file name, unlike the tentative design where "downloading" and "copying" may be part of the file name for example.

The "Applications would be able to safely exit while the transfer is ongoing" part might be a big challenge. The following post on facebook and comments on it from ex-Meego employees explains the issue:

Zeeshan Ali: anyone know who worked on 'transfers' ui in #N9 ? We need something similar in #gnome and have some questions about implemention

Josh Soref: Ask Adele Simula or Tuukka Tolvanen?

I'm curious about your questions, as BB10 has a Transfers UI.

Zeeshan Ali: Josh, Thanks. So here is the design page: https://live.gnome.org/Design/Apps/Transfers

My question is how to implement " Applications would be able to safely exit while the transfer is ongoing"? For this to happen, we must have a separate app/process that does the actual transfer and handing over transfers might involve state/cookies (including security info).

So I would like to know how they actually implemented transfers. Was it a separate app or apps doing transfer don't actually exit and only the UI is hidden from users.

Josh Soref: From memory there was debate about feasibility of passing the credentials to another process. 
The API that I found appears to have given up on that. Which means that a download halts or fails when the requesting process ends: http://meego.gitorious.org/meego-sharing-framework/transfer-ui/blobs/a730089219133e9bb66b9965d5a6e7e2a83ca67e/libtuiclient/examples/tuiexample.cpp

Josh Soref: The other problem was that the browser team wasn't interested in sharing its responsibility for owning downloads with another process. And there were credential lifetime concerns.

Zeeshan Ali: so that means, the UI process remains alive while UI is hidden or every UI that does transfer had a D-Bus backend that did the actual thing. How did browser handle it? In N9, the browser can be safely quit without failing the download.

Josh Soref: On the n900 the browser was two processes:
1: ui
2. rendering-engine daemon

In that model, quiting the UI didn't have to terminate ongoing transfers. I'd assume the same general model applied for the n9 browser.

Zeeshan Ali: ah ok but I'm wondering if that is what every app did.

Alexander Bokovoy: Zeeshan , all server code is on gitorius.

Alexander Bokovoy: https://meego.gitorious.org/meego-sharing-framework

Alexander Bokovoy: In detail. We needed to differentiate uploads and downloads. Both reported their status to Transfer UI which is a d-bus daemon that also had a UI you could launch via status menu or from an app. This UI is only showing progresses, the actual activity happens in the app that registers the transfer. 

Uploads were handled by webupload engine. It supported multiple plugins that were doing actual uploads in a separate processes. The engine shuts itself down when no processing left (and started on d-bus activation). Webupload engine was actually registering transfers on behalf of uploader.

In case of uploads, users were selecting what to upload in an application UI or application could have called Share UI via d-bus, passing request to show a UI to select destination to share. The actual Share _UI_ implementation Nokia decided to keep proprietary but the rest was published. Now there is QML implementation of that proprietary code as well, available at the same place on gitorious.
Browser was handling downloads by itself, only registering to Transfer UI that it is there. Actually, both Nokia browser and Mozilla -- you can find support for Transfer UI API already in Firefox upstream code. Both did it via separate process that runs in background since UI and actual rendering parts are separate processes both in Nokia browser and in Firefox Mobile.
Other apps -- Feeds had feed engine that ran in background and reported its update status to Transfer UI, Email synchronization did the same. Unfortunately, for the latter two their code was never published.

Olli Salli: Nice to see experience gained in our N9 endeavour being passed on and utilized 

Alberto Mardegan: I'm not directly involved in it, but I hope that we can reuse at least parts of the MeeGo Sharing Framework in Ubuntu:
https://blueprints.launchpad.net/ubuntu/+spec/client-1303-share-service

-- ZeeshanAli