Christian Boos wrote: > >>What could also be done is to move all the plugins not modified since 3 >>or 4 years into an /inactive folder with the same internal structure. It >>should be possible to revive a plugin in a similar way than it is today >>to "adopt-a-hack", moving it away of /inactive. Conversely, once a year >>move there the plugins who just entered their 3rd or 4th year of bit rot... >> >>That would also clarify things and avoid having too big folders even in >>the new scheme (the plugin/ folder in particular). >
Christian beat me to it on the inactive plugins idea, I think it's a great addition it will also make adopting a hack easier and quicker if a plugin is inactive and someone requests adoption you can do it immediately. Christian Boos wrote: > >>If caching and invalidation logic proves to be difficult, take the >>plunge and migrate to 0.12dev where you could use the cached attributes >>(see TracDev/CacheManager) ;-) > > -- Christian > I don't know if you can control your server setup or not but if you can the following might help speed things up. 1) Set the Cache-Control header for static files to something high since these won't change frequently 2) Set up a reverse proxy, my preferred method is to use an nginx front end that handles all static files and proxies anything dynamic back to apache running mod_wsgi. I find that setup very fast and kind on server resources, if you like the idea and want a hand setting it up let me know. ~Rowan _______________________________________________ th-users mailing list [email protected] https://lists.trac-hacks.org/mailman/listinfo/th-users -- View this message in context: http://n3.nabble.com/trac-hacks-org-on-Trac-0-11-release-candidate-1-tp74447p97762.html Sent from the th-users mailing list archive at Nabble.com. _______________________________________________ th-users mailing list [email protected] https://lists.trac-hacks.org/mailman/listinfo/th-users
