On Mon, 26 Feb 2007, Mike Taylor wrote:
I've been reading the design list and following along in questions during
meetings and would like to suggest that from this point on we use Backup and
Restore in place of the various phrases when describing the following:
Allow the user to create a complete backup of their Chandler data in a manner
that is cross-platform and schema-version independent.
Disagree:
While having this capability would be very desirable, the name "Backup and
Restore" is already taken. The existing "Backup and Restore" functionality is
a complete, non-lossy, cross-plaform backup of the user's repository. It is,
however, *not* schema- or format- independant and *cannot* be used alone
during a schema upgrade.
It is my understanding that the planned "Dump and Reload" feature, on the
other hand, is much more schema- or format- independant and is intended to be
used for user data migration during schema or format upgrades. Because it is a
translation from one format to another, "Dump and Reload" is likely to be:
- lossy: until all data in the repository is translated, it is lossy.
- slower: "Backup and Restore" essentially makes a copy the repository data
files and is inherently faster than a format translation.
- hard to implement: the usual 80-20 rule is very applicable here.
Until "Dump and Reload" can do all of the above (including what Backup and
Restore does), using the word "Backup and Restore" is misleading.
Now, it has been said before, with reason, that the name "Backup and
Restore" is also misleading because it doesn't include the schema/format
portability feature and users are bound to expect that.
It is up to us to present (and name) these features in such a way that they
don't confuse things and set user expectations correctly. There are several
solutions to this, of varying difficulty:
- Conflate the two (what bear is proposing, apparently) and is hardest.
- Rename "Dump and Restore" to "Migrate User Data" so as to not confuse
things. It could be renamed to "Migrate Repository" once it's no longer
lossy. This has the advantage of being easier to implement and improve
over time. The boundaries of what consititutes "migratable user data" can
be shifted one stage at a time without lying too much about expectations.
- Rename "Backup and Restore". I can't think of a good different name,
something with "Repository Copy" or "Repository Duplicate" comes to mind
but they don't have the nice to-and-fro of "Backup and Restore".
Suggestions are welcome.
- Make it clear in the docs and UI (File->Backup... and File->Restore...)
that "Backup and Restore" does *not* support schema or format migration.
Andi..
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
