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

["Rodrigo Peretti/OTT/OTI" <Rodrigo_Peretti@xxxxxxx>]

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

It is up to the implementor. No support for copy/cut/paste will be 
specially provided. It was just an example of possible use.

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

Everything but project location (as stated on the proposed API).

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

No but there's room for including it later (when we understand what it 
really means and the best way to do it == we need convincing use cases).

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

Agreed. It can and will be handled at the implementation level. We have in 
mind the same compatibility we have between Eclipse workspaces, i.e., a 
greater version of Eclipse can use an old workspace but not the other way 
around. 

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

That's a hard question. I can't really anticipate that. The nearest 
example we have is in the VCM world. In R1.0 it is not possible to load 
CVS modules as separate projects. And a lot of users wanted this feature 
that ended up included in 2.0. 
I would say that someone someday will want to have that but will not be 
the average case. Today, my answer would be to use some other export 
mechanism like zip and file system ( already provided by the UI ).

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

No. Users asked many times about this kind of project sharing on the 
newgroup and logged a feature request on bugzilla.

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

Seems that we should clarify the API. It means that the force parameter 
will be the final decision when a file already exists in the file system 
(but not in the workspace) and you are importing a file that should occupy 
the same location.

> * Why is export called overrwite but improt called force? 

Good question. :-) I believe there is no good answer for that. Changing 
the name to force makes it consistent with the rest of the resources API. 
Will do.

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

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...).

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

It is already true with other resource APIs like create. So I believe 
whatever actions the UI is taking on those cases, it should take on this 
one as well.

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

Yes, as discussed above.

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

Discussed above.

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

In fact, you are already able to do it . Just think about the VCM plug-in. 
It does not make use of any internal API from Core and it does the job of 
"importing" a project from a CVS repository. The amount of metadata that 
is not accessible by public API is not big.
The opportunity here is to have everything grouped in few API methods plus 
the possibility of, in the future, add metadata information that is not 
available through API.


Thanks for the input. Officially, this RFC discussion finishes today but 
as this was the only "public" comment on it, we'll extend it until 
tomorrow.

Rodrigo