[Chandler-dev] Reload is not import

Morgen Sagen morgen at osafoundation.org
Fri Apr 13 14:37:26 PDT 2007

On Apr 13, 2007, at 1:35 PM, Andi Vajda wrote:

> On Fri, 13 Apr 2007, Morgen Sagen wrote:
>> #1 I proposed earlier to solve by creating such out-of-the-box  
>> accounts outside of //parcels and instead in //userdata so they  
>> get dumped like any other item.  What I think I left out was that  
>> they should be given fixed UUIDs so that during reload the user- 
>> modified account items will have their data applied to the out-of- 
>> the-box items (and avoid creating duplicates)
>> #2 Preferences are handled by explicitly yielding the appropriate  
>> records within translator.finishExport( )
>> #3 Is handled by a combination of #1 and #2: the sidebar is given  
>> a fixed UUID, and also its collection-membership records are  
>> explicitly yielded in finishExport( )
>> So reload should mean "start with a fresh repository, load parcels  
>> (thereby creating out-of-the-box items), then reload dump"
> Giving passwords a fixed uuid is the same as saying "everyone gets  
> the same password". If that is not the case, then there is a  
> contradiction somewhere.
> If, for example, I send a password item around, I do not want mine  
> to have the same UUID as yours. But, you're going to say "we'll  
> never do that". If passwords are items then someone is going to  
> eventually. Really, fixed uuids should be used with care and with  
> the meaning "two items with the same uuid are the same item,  
> universally (the U in UUID)".
> Andi..

Yeah, you're right -- fixed UUIDs for user modifiable items should be  
used with care -- we do use it for the Sidebar collection, and  
perhaps that's ok.

So instead what I would like to now propose for dump/reload of out-of- 
the-box account items is...   to not have any.  The only reason we  
create them in installParcel anyway is so that the Accounts dialog  
will have something to show.  What if the Accounts dialog created  
them on the fly -- and only if needed?  The Accounts dialog could  
look to see if the currentSharingAccount reference points to an item,  
and if it doesn't then create a default one.  If a dump file has been  
loaded in, the currentSharingAccount reference will already be  
pointing to an account item, so there is no need to have an out-of- 
the-box one defined in installParcel at all.  Thus we can remove the  
special casing in translator import which deletes an out-of-the-box  
account if it's not being used. (Actually I already removed that  
special case code when I assigned UUIDs to the sharing accounts.)

Brian K, does this work for email accounts?


More information about the chandler-dev mailing list