Berylium-2003-03-04 is released today, with a gajillion bug fixes, performance optimizations, and an upgraded policy system. If you run your own, download this important update from the release page. Otherwise, read on for the news...
In this update:
- Reformed Policy System
Access control, what we call policies in the Berylium world, is critical infrastructure for most content management systems. Policies determine who gets to add which things to a site, and whether they can edit them later. Policies also determine who can see an object based on that object's status and whether or not it's public.
Policies are role-specifc-- for any given object, there is (by default, anyway) a policy for editors, writers, members and anonymouses.
This release reforms the previously existing policy mechanism, and makes it both flexible and consistent. Flexible because in theory, different objects can have different policies determined by their location within the site. Consistent because authoritative policy checks are now one of the last operations performed before a database update. Contexts can be written to override policies (a member must be able to modify the p_subscriptionList property of a document in order to subscribe to it, for instance) but malicious users will not be able to do so on their own.
- Performance Enhancements
It takes a lot of time, relatively, to format an object for display. There's the database lookup, text processing (including BML parsing), URL synthesis, date and time formatting, and policy processing should only have to be done once per object, no matter how many times the object is rendered in the current request.
One example where this comes into play is in a long list of documents that all have the same author. Previously, that sitemember was looked-up in the database and processed each and every time it was needed on the page. Seems kinda silly, right? I thought so, too, so I fixed it.
Other optimizations include checks to make sure that certain operations, such as policy lookups and URL synthesis only occur once per object, no matter how many times they're called. These frees context authors to be as liberal as they want about calling something like applyPolicy() without impacting performance.
By Chris Snyder on March 4, 2003 at 8:04pm