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

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

I believe I misunderstood what Randy said and what you pointed out from 
his comments and that's where the confusion started.
See <RP2>

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

Hi Rodrigo, 
I'm not quite sure I follow. Here are some questions to help me understand 
the concern you raise. (thanks) 

<RP>It seems that an approach having a separate file holding the metadata 
dropped into the project content area can be brittle. 
</RP> 

<Greg> 
Can you clarify what specifically you view as brittle is it: 

1)  [my original comment] 
        Always having a meta data file in a project brittle while it is 
loaded in the workspace. 

2) [randy's mod] 
        Keeping the meta data as is, but provide api to get it & create a 
project from it. The intent being an exporter would just have to call the 
api to get the meta data flattened, and conversly use the flattened to 
remake the project. 

With respect to #1, aren't we already encouraging other components to 
store their meta data as files (vcm, web etc). 
With respect to #2 it doesn't seem any more brittle than the original. 

</Greg> 

<RP2>
I understood that Randy was suggesting to have an API that would generate 
a file holding only the metadata and that it would be used together with 
the zip or file system exporters in order to export/import a project. So, 
I assumed that the file would be generated and put into the project 
content area before using zip/file system exporter. Having this kind of 
file around would be brittle. I did not assume that the file would be 
maintained on the content area.

About #1 - Yes, we are. So, I believe what you are suggesting here is that 
if we want some kind of metadata to be shared, we would have a file 
corresponding to this metadata in the project content area (like 
.vcm_meta, .classpath, etc...) instead of having it hidden in the 
.metadata folder of the workspace. Interesting... Maybe having a .metadata 
folder in the project content location in order to put any file that is 
intended to be shared across workspaces. Sounds good. I'd like to hear 
more about that.

About #2 - Agreed that doesn't seem  more brittle but I prefer the 
original approach. One file.
</RP2>
--------------------------


Seems very easy for 
this file to get out-of-date. Having a single file containing resources + 
metadata sounds more consistent. 

<Greg> 
I don't follow why this gets out of date easier. 
Some observations: 
*        If the export happens to a single file, then unless that file is 
a zip (for example) it means it is non standard (i.e. its special). 
*        Whether the projects contents are packged into one file that you 
cannot see into, or into zip (using standard export + meta data), 
        or into the file system it does not seem that the latter too are 
overly exposed to becoming out of date. The only wayt 
        this would happen is if someone manually wacked it. 
*        (related to the above) One could actually make an argument that 
keeping the existing export approach, and 
        whether we use zip or directory, it means the UI for example could 
opt to optionally keep the export up to date 
        without rewriting the entire wad. It seems like there is some 
benefits to the format we have 

I think I'd go back to Jeff's view and argue - do we have to have a 
specialized "wad" export (for lack of better words) or is there some way 
to use our curent export strategies if we simply had more 1st class 
treatment (again not ideal words) of meta files. 

I hope my questions are clear - I couldn't find quite the write words to 
express my thoughts. 
</Greg>