[Design] Design Session Today @ 2:30pm - Dump and Reload

[Sheila Mooney]

John,

Thanks for the feedback. When Mimi and I met with Bear originally we  
discussed this option as well. There were some questions around the  
difficulty of accessing an old Chandler repository. I know that we  
can currently detect the existence of a previous version of the  
repository but Bear wasn't sure how easy it would be to open up an  
older one and dump into the new version. He mentioned that the old  
one would be locked (something like that). This is something we  
wanted to discuss in the meeting today.

Cheers,
Sheila

On Feb 13, 2007, at 10:32 AM, D John Anderson wrote:

> How about doing what most other programs do: When you run Chandler  
> after installing a new version we prompt the user to explain that  
> we'll upgrade their repository and giving them the option of making  
> a backup?
>
> John
>
> MANUAL Workflow
> 1. Go to File menu and select 'Back-up data'
> 2. Chandler translates user's data into EIM and saves it as a .txt
> file somewhere it knows about.
> 3. User installs new version of Chandler
> 4. User goes to File menu and selects 'Restore data'
>
> AUTO-MAGIC RESTORE Workflow
> 1. Go to File menu and select 'Back-up data'
> 2. Chandler translates user's data into EIM and saves it as a .txt
> file somewhere it knows about.
> 3. User installs new version of Chandler
> 4. On install, new Chandler detects that this is a version upgrade
> for the user
> 5. New Chandler finds user's data in EIM format and imports it into
> new version of Chandler
>
> POTENTIAL UPGRADES TO THIS WORKFLOW
> 1. User is given a choice as to what data they want to restore (which
> collections)
> 2. The Back-up portion happens automatically before a new version of
> Chandler overwrites the previous version.
>
> On Feb 13, 2007, at 10:23 AM, Sheila Mooney wrote:
>
>> So for today's design session we are going to review the current  
>> dump and reload plan - specifically the proposal I sent out to the  
>> design list on Jan 25th. Mimi has also outlined the workflows at  
>> the bottom of the proposal.
>> http://lists.osafoundation.org/pipermail/design/2007-January/ 
>> 006146.html
>>
>> Some of the things we would like people to be thinking about....
>>
>> + We are planning on consolidating all the current features into  
>> one step. Do we need to still have these available separately?
>> + What sort of customization do we allow users? Are there cases  
>> when they would only like to migrate certain data ie: particular  
>> collections, settings only?
>> + What are the places where things can go wrong? What kind of  
>> error scenarios do we need to handle?
>>
>> The goals for today's meeting are....
>>
>> + Review the proposal - get feedback on general direction
>> + Identify issues/problems that we haven't thought of
>> + Identify what areas of the UI still need to be spec'd out
>> + Tease out actual work items and identify who is doing what
>>
>> For those in the office, the meeting is in Whoville.
>>
>> For the remote folks, we can use my bridge...
>> 1-800-391-1709
>> 822421
>>
>> Cheers,
>> Sheila
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070213/db8adea7/attachment.html