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

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

Rodrigo,
Here are my comments on the import/export proposal.

* To support cut/copy/paste & drag/drop do you expect to include multiple transfer formats (e.g. one that tries to move meta data vs, one that doesn't)

* Does METADATA_PROJECT_DESCRIPTION cause all parts of the IProjectDescription to be written out (natures, name, location). I believe yes but wanted to confirm.

* Are tasks (as opposed to problem markers) associated with projects, folders, files exported?

* Typically when doing an interchange/exchange format it is useful to include version numbers for the format, and potentially for the platform itself. I did not see this covered. This means this approach could likely not be used for migration down the road, and it could potentially cause problems if you hand me an export done on 3.0 but I am using 2.0 (perhaps 3.0 changes the project description). In ENVY they found many cases to be thankful for having the version info.

* Do you expect there to be use cases for wanting to import a subset of a project. For example you export a large project and I want to only import portions of it. I am not personally making an argument for this - I'm just asking the question.

* Is the primary driving force behind this the UI or JDT teams - since without their support it won't get manifested to users. 
(Just asking the question because the idea is clear - just not who is pushing)

* The spec for import indicates "The projects must not exist in the workspace." and "The force parameter indicates whether existing files should be overwritten. ". I must be confused because these two statements seem to contradict one another.

* Why is export called overrwite but improt called force?

* 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?

* Do you expect there is a need for confirm before overwrite? For example it seems a UI has to choices, call with force true or false. If they call with false then they only get told it fails, and would have to delete everything (the spec says a partial import would hae 

* import - "If the operation fails, projects might end up in a half-imported state and none of the projects can be guaranteed to have been imported
correctly. " - why does not core not clean up? It seems that you will be requiring the caller/client to have to do the cleanup work?

* It seems that I can set overwrite or force to true but then if a collision happens the operation just stops and reports that error potentially leaving things half done. This would require the UI cleanup (although core should do that), and then if the user says "yes go ahead" the UI would have to start it all from the begging with force/overwrite being true. Typically when an overrwite happens there is a yes, yes all type confirmation given however there does not appear to be sufficient support to provide this?

* If meta data was presumably stored in plain files inside a project, wouldn't this mean the need for specialized import/export facilities would go away because it would not just be a matter of copying a folder tree from the file system. One could envision a simple ui change that says create a project from this folder - for import.  What am I missing here?