Introduction and an Idea

[Dylan McCall]

Hi,

Here's a bit of a tangent on my part, but ideas grow well when there are
a few different ones! I was thinking that the conventional "backup tool"
is a rather unnecessary, kludgey design. Perhaps this could be
accomplished with a "backup:" URI implemented in gvfs, where backup
destinations get configured via a special GUI but everything else done
through normal file management. This way functionality magically grows
as file managers get smarter and as configuration tools gather the wits
to provide easy drag & drop for the configuration files they control.

Dropping a file in the backup area would create a link to it, then a
backup daemon would do its thing, perhaps triggered upon the insertion
of a particular device. By doing it as a virtual file system, the thing
is modular. Different backup solutions could be created, perhaps that
specialize in revision control or that talk to box.net, without exerting
any pressure on the user.
Tidy and integrated :)

Recovering backups is on the other side of the spectrum. A more
specialized backup recovery GUI would do the trick there since it is a
different kind of operation - one that the user expects to give his full
attention to and expects a rich interface from in return. Ideas for rich
interface:

      * The Nemo file manager organizes files by date with a calendar
        view. Could be cool to explore similar ideas for some aspects.
      * We should present revisions of files. With backups happening
        passively, a super intelligent system could do them to multiple
        media. For example, backups could be made to a 1 GB box.net
        account as well as a portable hard drive, where the more
        important files are kept up to date on box.net (since of course
        not everything can be stored in that little space!) and the
        portable hard drive has its main priority set to storing
        significant modifications of files over a long period of time. A
        backup of backup settings could be quietly done to a selected
        USB flash drive, as a hidden file on its base directory. Open
        the restore tool and it detects all media with backups on them,
        then merges them into a single view. With the backup of backups,
        it could suggest other places the files may be. (On a different
        topic, wouldn't it be awesome if the OS could keep track of such
        things all the time?)
      * Autodetect configuration files from programs and offer to
        restore them.
      * Drag and drop. Hold nothing back. On that topic, we should be
        able to yank configuration details from their GUI tools and dump
        them (maybe archived), wherever we want such as into backup
        directories. I think the holy grail there is having something
        like the Tango Window Experiments but even cooler; the top left
        of every configuration window (gnome-control-center stuff,
        gconf-editor and Preferences in every application) becomes a big
        emblem that represents the file being controlled by said
        interface, which is draggable and droppable just like any other
        file in a file manager and can have another copy of itself
        seamlessly dropped on top... but that's someone else's battle.
        (Well, actually I'm working on it, but you can too :P).

Another thing that needs to be pondered is letting other applications in
on the backup and restore thing. For example, a "Backup my photos" and
"Restore my photos" button in F-Spot that talks to the backup system.
Programs talking to that system could be a simple as accessing a backup:
and restore: URI. The restore URI could mirror the existing file
hierarchy, so a program "just" stops reading file: and starts reading
restore:

The big problem with backup tools today is that it's where everyone's
user interface paradigm (including our own) crumbles into dust. That
user interface is both application-centric and file-centric. In short,
sometimes the user runs an application to open a file; other times he
opens a file to run an application. Sometimes he does both, sometimes he
does one and a half and sometimes he does neither, opting to use a
sledgehammer.

Take, as an example, uploading a photo to a web site. You can open the
site in a web browser and use their Browse... button. That gives you a
basic file browser. Your photo is stored in the F-Spot photo library.
Good luck finding it without opening F-Spot and asking it for the path.
That is not intuitive. The other option is to open F-Spot itself and use
its "Export to PhotoShareSite" function. Thus is the big problem. F-Spot
only supports a few photo share sites, and that site of course doesn't
provide an upload path itself; F-Spot has to provide that on its own. So
we have two methods for users to work with, and neither method is
directly compatible with the other.

At this point both methods of getting and making content are here to
stay, and that may be for the better. We do indeed have two kinds of
applications: Ones that treat files as workspaces (word processors,
photo editors, video converters), and ones that treat themselves as
workspaces (games, photo managers, _file browsers_). What we need is a
happy medium technology that allows those two kinds of applications to
talk to each other more directly, not just through the VFS and the file
browser widget supplied by GTK.

Back to the web site example, with the fancy new world order:
User goes to the web site and clicks "Browse...". Instead of a file
browser, a fancy (and of course semi-transparent) content finder widget
appears. It reads into the file type filters to realize that the user
wants files of type image/jpeg image/png. Heeeey... the user's favourite
applications that provide those are Cheese, GIMP, Generic File Browser,
and F-Spot! The user sees a choice between those four content providers
and knows that he has the photos stored in F-Spot Photo Manager (not
"the folder that F-Spot Photo Manager is meant to be abstracting" as the
user must think in the present). In the future he chooses F-Spot,
selects the photo using the F-Spot interface he is accustomed to and is
done.

That would necessitate some extra work for everyone, but more in adding
simple tubes than refactoring anything.

Yes, this all comes back to backups at some point. We cannot expect
backup tools to be user friendly until the problems inherent in file
management with our user interface are tidied up, because backing up and
restoring files needs a fair bit of contact with the matter. It would
help the user very, very much if a file looked the same aboard the
backup media (eg: from the backup restore tool) as it looks in F-Spot.
That can be done by allowing a program like F-Spot to browse a photo
library when the user opens it, because that program is really nothing
more than a file manager. Why only use the one generic file manager when
F-Spot is perfectly adequate for its own content? Indeed, this doesn't
happen today, largely because the interface has been built with the
generic file manager (Nautilus in our case) on top as some omnipresent
super-being, when really it should be nothing more than a nice fallback.
In short, everything needs to fit into the same flow of steps. For a lot
of user's, their collection of files is really an assortment of
libraries, each of which belongs to a different application that you can
dig up from GNOME's Known Applications list.

I am confident that some day the file management mess will be tidier, so
the best way to help that along is by not doing anything particularly
kludgey for /this/; by building something that will stretch.


So there is my thought on the matter. Rather different from yours, but
we certainly agree on one thing: Backup tools are nice and this is a
place where we CAN innovate.


Bye,
-Dylan McCall

PS: Now /that/ is stream of consciousness writing. Speaking of cruft...

> Hello all,
> 
> This is my first post to ubuntu-devel-discuss, but not my first posting
> to a linux development list. I posted to ubuntu-devel after being
> directed there, but that group is literally ubuntu developers only.
> Anyway, I was heavily active on the lists in the earlier days of BusyBox
> and uClibc, as well as a few other packages along those lines. Rather
> than drone on, I will try to keep this post mostly business.
> 
> I would like to discuss Brainstorm Idea #1
> (http://brainstorm.ubuntu.com/idea/1/) with you. I feel that backup and
> restore is an extremely important topic as we move further and further
> into the digital future. Media such as digital photos, home movies,
> school and university work, and much more are all at risk. This is
> something that many of us know too well.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20081110/335569b3/attachment.sig>