[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re:[platform-core-dev] RFC 0002 - Importing and Exporting Projects
|
See <RP2> (Omitted the ones I agree or did not have anything to add). The
proposal has been updated on the web as well (small changes related to
this discussion).
--------------------------
<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>
<RP2>
Seems interesting to have API to get metainfo (like the version) about the
export file. Will wait for further UI requirements before proposing it.
Didn't get your last question. What version number is that? Core does not
have version numbers associated with resources. If it is version numbers
like VCM has, the answer is not for now and will depend on how VCM stores
these numbers.
</RP2>
--------------------------
<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>
<RP2>
Sure. Subscribed to the UI list and will send a message to them as soon as
we have something working (at least on a nightly build).
</RP2>
--------------------------
<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>
<RP2>
Yes.
</RP2>
--------------------------
> * 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>
--------------------------
<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>
<RP2>
I understand your concern and it is valid. For now we do not have any
plans on making all the metadata available through API. For example,
things like the "resource tree" and the various information bits held on
"ResourceInfos" might never become API. The export/import mechanism can be
a way for sharing this metadata through workspaces without committing to
undesired API.
But, as you point out, the first implementation of it could be done with
existing API and we do not know if it is going to evolve to what I pointed
on the previous sentence. It could end up as only a convenience API. If
you or someone else have more points on it, please comment.
</RP2>
Thanks again,
Rodrigo
