> i loved the 0.8.2 place of the cache dir, what was wrong with that? it's > easy to find and get rid of when needed, it's easy to say whether it's > there or not, zero clutter cost.
There was nothing "wrong" with it, but it had some drawbacks which we wanted to remedy. Particularly, we wanted to support developers doing multiple applications on their machines. Which is the case for most of the core developers who easily work on 10+ applications at any one time. Cache re-use was a major time-saver. > and i can't think of any use case > where it would make sense not to have write access to the development > dir either. (this doesn't mean there isn't any, of course) Which "development dir" do you mean? > those being said, i'm also against a system-wide cache dir because we > have multiple people working on one development machine (via x > forwarding) who might need to work with different versions of qooxdoo. Which should be fine, since they they will have different cach objects. But there *is* an issue with concurrent access, when two developers are accessing the same cache object simulatneously. So this might mandate separate caches for separate developers. But this is all easily set up using the CACHE macro. > however, if thomas is going to insist on getting the default cache dir > via gettempdir(), at least have the default config.json in the skeleton > "./cache" as cache dir by default. Well, that would defeat the whole idea of "default", wouldn't it?! > this way at least, i'll instantly > know where to change the place of the cache dir if i ever want to. I don't get it. Nothing has changed in this regard. The default is set in base.json, and you can always override it in the app's config.json?! T. > > best regards, > burak > > thron7 wrote: >> Hi Derrell, >> >> thanks for your thoughts. >> >> >>> Most Linux distributions either clear out /tmp each time the computer >>> boots, >>> or mount /tmp on a virtual file system (e.g. tmpfs) that is recreated >>> on >>> each boot. I believe this means that on a laptop that is rebooted a few >>> times each day, an application in development would require a complete >>> rebuild following each boot -- a very long process, of course, with any >>> substantial application. >>> >> >> Mh, I was not aware of that. I have been working with Linux the past 10 >> years and never had my /tmp been cleared automatically. But then, I'm >> not >> using one of those modern desktop versions of Linux. And actually, since >> 2 >> years I hardly reboot, I only hibernate. - But of course, I'm interested >> in other people's experiences. >> >> > > well i'm using gentoo and it has been clearing /tmp for some time now. > >>> I >>> would suggest using a different environment variable variable name, >>> e.g. >>> QOOXDOO_CACHE_DIR, with a fallback to TMPDIR. >>> >> >> I'm not sure I completely understand you here. For one thing, we are not >> evaluating environment variables. Technically, we use the gettempdir() >> function of one of Python's standard modules, tempfile. This in turn >> does >> evaluate environment variables, but also applies a lot of platform >> logic, >> so we don't have to worry about it. Since we are running >> >> But more importantly, the TMPDIR *is* the fallback already. Just set >> your >> CACHE macro to some other path and you're set. If you don't like the >> TMPDIR location, just override it. Config macros are our way of >> tailoring >> the system, and I wouldn't want to add another mechanism, like >> environment >> variables, without compelling need. - If you are running multiple >> applications on your machine, and want to maintain a central setting, >> just >> create some "site.json" and include it in the individual config.json's. >> >> But sure enough, while this should help you individually, the fallback >> setting should be sensible for most people, so if a lot of people have >> the >> issues you describe we should re-consider the default. >> >> > > > ------------------------------------------------------------------------------ > Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT > is a gathering of tech-side developers & brand creativity professionals. > Meet > the minds behind Google Creative Lab, Visual Complexity, Processing, & > iPhoneDevCamp as they present alongside digital heavyweights like > Barbarian > Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com > _______________________________________________ > qooxdoo-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel > ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
