Re:[platform-core-dev] RFC 0002 - Importing and Exporting Projects - c

["Greg Adams/OTT/OTI" <Greg_Adams@xxxxxxx>]

A brief follow up to your corruption observation because it made me think of a question about the spec, and I also wanted to provided an observation based on yours<g>.   Thanks for your patience as we discuss this proposal.





-------------------------- 

> * If I have overwrite (or force) false, and it detects a conflict case 
does this mean that some partial import or export has occured - and thus 
consequently the UI must do a cleanup? 

rp>Basically yes but the user might be the best person to decide what 
should 
be deleted. We did not include clean up code in the import API itself 
because it seemed we were not in the best position to decide what should 
go or stay. Besides, that is the case with most of the resources API 
(copy, move, etc...). 

<greg2> 
Disagree (but not strongly)- I actually don't buy this. I'm hard pressed 
to think of a use case where as a user I wouldn't just go and delete it 
all and start again. I would be very nervous about what actually got 
copied. 
</greg2> 

<RP2>
I understand. I also do not have a strong argument in favour. But I 
prefer, as a user, to clean up things myself (not all the times, though) 
if something goes wrong. Here is an extreme use case: suppose the export 
file is corrupted but anything you can recover from that is worth a try. 
If core or UI delete things when something goes wrong, the user does not 
have a chance to recover these pieces of data.
</RP2>

<greg3>

In the big-file case I am not sure what the spec'd behavior is if you hit a corruption. Do you stop immediately or continue just skipping the bad things. If you stop immediately then it would be limited in what I can recover. Things after the corruption go unrecoverable.

This seems to suggest we would be safer to avoid a special big-file format. If it was standard export with meta flattened into it then a user could recover parts as needed. 

</greg3>