I started working on the "migration tool". In this thread I'd like to
share ideas about defining its goals, its implementation design and
maybe even a roadmap.
Important things first: the name!
====================================
I propose to call it "newborn". It is:
* a word game on "moving from a live to a live"
* (arguably) a nice Muse song
* in Italian, it is similar to "niubbo", which in turns means "newbie",
so conveying the meaning of "easy to use"
What is it useful for
=======================
When a user changes OS, transfering important data to the new one can be
lengthy. This is a general problem, but affects freepto more
specifically because that's what updates are: truly new freepto
installations.
With this tool, a user can simply migrate "important data" to a new os.
We say important data to mean that our efforts will be towards the
import of non-repeatable data: encryption keys, personal data, etc. We
will care much less about moving "settings", for two reasons:
* moving settings could destroy the whole point of updating freepto
* the user can re-set them. It's boring, but definitely different from a
data loss.
Design
========
NOTE: this should be integrated with considerations about the User
Experience. anyway, that's a first draft: take it, change it, reject it.
* a memorabilia is something that could be migrated.
* newborn contains "explorers": pieces of software that will scan your
old installation looking for "memorabilia"
* the user can choose which memorabilia she wants to import
* retrievers are pieces of software that can import memorabilia
Example: we could have an explorer for gpg keyrings, one for pidgin+otr
related stuff, one that looks for non-hidden directories inside home
directory, one that looks for firefox bookmarks.
After running, the gpg explorer founds both a pubring and a secring. The
otr explorer founds nothing.
The "directory" explorer founds a Documents/ and a Music/ directory
The "firefox" explorer founds nothing.
The user is presented with four memorabilia: pubring, secring,
Documents/, Music/. She selects only Documents/ and secring.
The corresponding retrievers run, effectively importing those data.
Modularity
-----------
For how it is designed, most of the code is put inside the
explorer/retriever things. This is intuitively modular.
Building a proper "pluggable" system is outside the current goals, but
could be added later quite easily, if needed.
Implementation
----------------
As with most of the freepto-related software, newborn will be written in
python. Its interface will probably be in Gtk3, but I leave this
decision to paskao.
Things to consider
--------------------
Modular design is nice, but we should remember that providing feedback
to the user has much importance.
We could bind the standard python logging module to nice GtkWidgets, so
that the user can see informative messages.
Status
========
I have some ugly but working code. It was written months ago by ginox
(thanks!), and now I am polishing it. I hope to publish a first draft of
it soon.
