[kepler-dev] proposed changes to .kepler

[David Welker]

Hi Derik,

I think this is a great idea. We definitely need to distinguish  
between these two ideas.

I also prefer solution a).

As far as naming goes, I prefer cache to temp, since we have a history  
of referring to the Kepler cache. Also, you could get rid of the  
persistent directory, and anything that is not in cache or temp would  
be considered persistent by implication.

These are all details though and not that important. Overall, I prefer  
something like a) first, but I could live with c). I think b) should  
absolutely be avoided, as this would make it challenging for people to  
delete all of their cache without use of the build system.

David


On Nov 18, 2009, at 5:08 PM, Derik Barseghian wrote:

> Kepler devs,
>
> After some discussion with Aaron, Ben, Dan, and Chad, I'm wondering  
> if anyone objects to dividing .kepler into two different areas --  
> there would be areas for 1) persistent items (e.g. provenance  
> database) and 2) temporary items (e.g. cache). This would make it  
> more apparent which things could be deleted without serious  
> ramification (temp/), and the idea would be items in peristent/  
> should stick around and be dealt with during kepler upgrades for  
> backwards compatibility.
>
> Also, I think we should utilize the InstanceAuthNamespace in these  
> paths, so that items from different Kepler instances are separated.
>
> This could look like (imagine multiple namespace dirs):
>
> a)
> .kepler/perisistent/gamma.msi.ucsb.edu.OpenAuth.1278/
> .kepler/temp/gamma.msi.ucsb.edu.OpenAuth.1278/
>
> or b)
> .kepler/gamma.msi.ucsb.edu.OpenAuth.1278/persistent/
> .kepler/gamma.msi.ucsb.edu.OpenAuth.1278/temp/
>
> or c)
> .kepler_temp/gamma.msi.ucsb.edu.OpenAuth.1278/
> .kepler_persistent/gamma.msi.ucsb.edu.OpenAuth.1278/
>
> I prefer a).
>
> This partly came out of a discussion of bug 4514. I think the  
> configuration files could be stored beneath these new paths,  
> probably in persistent.
> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=4514
>
> A better solution might be to just have a .kepler to store temporary  
> things, and to store persistent items in an OS-appropriate location,  
> but I think this might be a larger change than we want to take on at  
> the moment, as we try to get 2.0 out of the door.
>
> Let me know what you think,
> Derik
> _______________________________________________
> Kepler-dev mailing list
> Kepler-dev at kepler-project.org
> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev