Forum OpenACS Development: Re: Towards OpenACS 5.9
In short, all these operations are faster in oacs-5-9
- acs_object creation: 16% faster
- acs_object deletion: 6% faster
- cr_item creation: 6% faster
- cr_item deletion: 9% faster
As mentioned above, on sites with millions acs-objects, the improvements can be mich larger. An update operation on the context_id of an acs_object dropped on our live system from 2.5 minutes to 10 seconds (under this context_id is a large tree of objects). On operations with leaf objects, the difference will be much less. The changes are especially good for large sites and improve the scalability of OpenACS.
=== OpenACS 5.8.1 acs_objects created 100000, total 85945ms, 0.8595ms / object acs_objects deleted 100000, total 152611ms, 1.5261ms / object cr_items created 100000, total 206543ms, 2.0654ms / object cr_items deleted 100000, total 432189ms, 4.3219ms / object === OpenACS 5.9.0 acs_objects created 100000, total 72457ms, 0.7246ms / object acs_objects deleted 100000, total 143823ms, 1.4382ms / object cr_items created 100000, total 193504ms, 1.9350ms / object cr_items deleted 100000, total 395428ms, 3.9543ms / object
there will be a beta2 release of OpenACS 5.9, which i hope to be able to package on the weekend. Among a few small upgrade glitches i've updated the timezone reference data. The old data was 7 years old, we have now 43 more timezones and many fixes and updates.
For example, just recently, the checker complains about minified .js files, which are not regarded as source code anymore. So we have to get rid of all minified files in the debian distro (and all references to it in the source). This affects mostly the rich-text editors. It looks to me as if the best solution would be to pull out the editors from acs-core and to make it own packages, which can be installed via "install from repository" in the future (... but that will require same refactoring).
Another problem are is the aolserver package in debian, which is in a very old state, but the the debian maintainers are quite unresponsive concerning bug reports. Hector has started to look into the details, how to getting a NaviServer package into debian (there is some work from the people at qcode.co.uk we can build upon). But in any case, the cycles are rather slow.
Short message: we are on it, we are getting closer to a release.
+1 for a stronger modularization with respect to external libraries.
As I have suggested earlier, I sympathize with the idea of having dedicated OpenACS packages for external JS libraries such as jQuery, YUI2, Bootstrap, etc...
These could follow a naming conventions similar to acs-* such as e.g.
But certainly, better approaches than ajaxhelper to handle complex js frameworks like bootstrap/yui/ext/... etc are as well needed, but that might be candidates for theming packages, since mixing theses is though...