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

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

Thanks for quick feedback. See <greg2> - mostly agreed with some brief follow up.

"Rodrigo Peretti/OTT/OTI" <Rodrigo_Peretti@xxxxxxx> Sent by: platform-core-dev-admin@xxxxxxxxxxx 12/03/01 05:41 PM Please respond to platform-core-dev

To:        platform-core-dev@xxxxxxxxxxx         cc:                 Subject:        Re:[platform-core-dev] RFC 0002 - Importing and Exporting Projects

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

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

<greg2>
Ack. I presume we can argue support for this would have to be above core because the d&d transfer formats are themselves above core.
</greg2>

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

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

<greg2> ok. I thought you exported project location aswell but just ignored it on input. </greg2>

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

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

<greg2>
I don't have a use case in hand. An argument could potentially be made that since we cannot share tasks via the repository it should not be a priority to share them through export.  I believe however that down the road shared tasks (in repo) will become an issue & then we'll need to visit it here. I strongly agree with your 'not unless there is a convincing case'
</greg2>

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

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

RP>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. 
</greg2> 
agreed. 
Suggest also you should make it possible via api to get at the version info of the export file via api. This would allow the ui to say things like "do you want to migrate this" and also to auto kick off migration/mutation after an import.

Do we expect to have project (folder, file) versions numbers written out
</greg2>

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

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

<greg2>
I agree - this does not feel like the common case. Most UI's would tend to also default to import all. In fact in VAJ we specifically added an operation that was "import the latest of everything in this repo and put it in my workspace" for the reason you describe.
</greg2>

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

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

<greg2>
Ok. Can you follow up with the UI mailing list to ensure they are aware of this since they will need to manifest it. I have asked a few of them to explicitly read it in case they have concerns.
</greg2>

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

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

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

<greg2>
Ack.  I presume this only happens if the project does not exist in my workspace, but the destination location turns out to have stuff there.
</greg2>

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

<greg> * Why is export called overrwite but improt called force?  </greg>

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

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>

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

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

<greg2>
Ack. I was under the impression in this case we did a bulk with no individual control but in the other cases the ui had individual control. My apologies for a red herring.
</greg2>

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

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

rp> Yes, as discussed above.

<greg2> Disagree - see above. </greg2>

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

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

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

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

<greg2> 
Exactly. So my observation is if all meta data is done this way - then doesn't it argue we actualy do not need special api, that things can be done using existing api? It could be argued to be unneccessary convenience api as opposed to being a new feature/facility.

Is our intent to be file citizens with all of our meta data.
</greg2>

--------------------------
rp> sThanks 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.

<greg2> sorry for the late reply. It took me longer than expected to read a ui proposal. </greg2>

Rodrigo

_______________________________________________
platform-core-dev mailing list
platform-core-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-core-dev