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

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

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

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

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>



<Greg3>
You got it.
Approach 1 - is addd a .metadata folder to each project and have core play by the same rules as vcm etc.
Approach 2 - is use a meta data file only on import & export

I'll confess to not being sold on the one big file.  It feels like we are inventing a new format, when we have existing export/import that work. In the past we've usually had  grief when using special files, and we sometimes find we have to keep adding & adding api as we want to add features. For example, assume we ever wanted to piecewise load folders from the file, we would need special api for it. But if it was a standard import/export format it would be doable without change.  If we wanted to show a user a view showing them the various available exported wads and the detailed contents of each, we can't do it without additional api (current spec'd api only gives us available projects).

But I get this terrible feeling that I am being dense and just missing the compelling argument.  

I would be interested to here what others say. Randy did you have a follow up since you also had comments & you are a client too.
</Greg3>