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

["Randy Giffen/OTT/OTI" <Randy_Giffen@xxxxxxx>]

In summary it is unclear to me why core would want to get into creating a projectExportFile. It seems to be just a zip that includes some metadata.
Why doesn't core simply add api to produce/read this metadata description? A file with this metadata could be added to the project/read from the project, on export/import with only minor modifications to existing File System and Zip wizards. 

See RG>>>

Nick Edgar 12/03/01 10:20 PM

To:        Randy Giffen/OTT/OTI@OTI         cc:                 Subject:        Re:[platform-core-dev] RFC 0002 - Importing and Exporting Projects

Randy,

I haven't been following this.  Have you, since it's related to the CCP story?
Could you please ensure that whatever they're proposing will meet the needs for CCP, and also makes sense as a UI operation for sharing workspaces?
Please also consult Tod since he's the current owner of the import/export wizards.

I noticed that the due date for comments is today, but I'm sure they'll not just delete any further input we may have ;-).

Thanks,
Nick

----- Forwarded by Nick Edgar/OTT/OTI on 12/03/01 10:24 PM -----

Greg Adams 12/03/01 06:19 PM

To:        Nick Edgar/OTT/OTI@OTI         cc:                 Subject:        Re:[platform-core-dev] RFC 0002 - Importing and Exporting Projects

someone on the ui team needs to comment.

----- Forwarded by Greg Adams/OTT/OTI on 12/03/01 06:18 PM -----

"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

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

RG>>> It is not clear to me that this proposal can support cut/copy/paste. 
Transfers (the classes which implement the code required for cut/copy/paste) are stateless. Any information they require must be placed on the clipboard. This can be real data as in the case of a text transfer or a reference (ex. filename) as in the case of a file transfer.

Performing project copy/paste within a workspace is easy. We just place a reference (path) for the project on the clipboard and then lookup the real project (to copy it) when we paste. 

In order to perform a cut/copy/paste across workspaces we need the metadata required to recreate a project in the second workspace. We don't need the actual contents of the project since we can just use a reference to the location of these contents.

The alternative (given the proposed api) is that cut/copy would create a temporary projectExportFile and place a reference to it on the clipboard. However this violates the principle of not doing any real work until paste (if you were just "copying" the project to get its name to paste it into a text editor then creating the export file is a real waste) . 

A comparison I would make is that VAJ had the abiltiy to create a jar or just create a manifest. Core should have api to create a projectExportFile (data + metadata) or just just the project metadata (so that it can be placed on the clipboard along with a reference to the data).

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

RG>>> To move tasks across workspaces (as part of a project or on their own) we will need to be able to "serialize" them to the clipboard (or a drag and drop record).


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

RG>>> I think the ability to show the user a yes/yes to all/no/cancel dialog when an overwrite situation occurs is a requirement (see IOverwriteQuery). We are able to perform this for current import/export because we are performing them one resource at a time. Without a callback from core for overwrite during project import we will not be able to make project import work like file system/zip import. 


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

RG>>> It seems to me that this is the direction (metadata via a simple api) that would be useful for the cut/copy/paste case.

And as Greg suggests a simple UI change to include/detect this metadata on export/import means that project export/import could happen with only minor changes to to the UI. 


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

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