Through discussions at work, we've decided to target some additional improvements to Syntax for this quarter.

Restructuring Metadata

Though we have cached metadata already for the 1.0 release, our improvements were a hack. We're going to try to ease our transition to 2.0 by restructuring the metadata classes to have a central class that manages metadata collection and communication. This change should be invisible to the application author as well as be backward compatible with existing databases, so we're putting it in the 1.0 branch and not the 1.1 branch. They will require database changes to support, most likely, so we'll be incrementing the version number to trigger the upgrade script. However we're committed to keeping them backwards compatible.

Improving Filtering Performance

Actually, I'm pessimistic we can achieve that much here. I already have a design for a new, more optimized search class, and the changes we're making to metadata should help. However, it's a big project and it won't be easy. Additionally, it will be a new, coequal search class with some real limitations. The tradeoff will be increased speed for 80% of the work we do. This will also probably go into the 1.0 branch for 1.01 or 1.02, as it should be just an additional API for searching and filtering. No existing sites should break, but new code won't be back-portable without upgrading. I've seen some other low-level things in the API that I think could be improved by not trying to be quite so general. There is a preg_match() and a eval() that get performed with alarming frequency in every syntax instance, and I'm not 100% convinced it's necessary, certainly for PHP 4+. Plus it annoyingly ties in Syntax data to the global scope, and that is always a Bad Thing. Fixing this will start us on the way to being able to root out the dependencies on register_globals that sadly exists in 1.0. Anybody interested in looking into it can examine the pxdb::import() and pxdb::import_var() methods. Braindump complete.

With the changes we thought were going to be in 0.0.5, we found that the CMS was stable enough (and used in production internally enough) to be called 1.0. So here's a tentative roadmap:

0.0.4 (current)

On the public SourceForge site, this is only the API, and is fairly badly out of date. We've made a number of stability and feature enhancements to it. However, we're going to abandon 0.0.4 as is, because it's not worth updating singly.

1.0 (main trunk)

1.0 has lots of feature and performance enhancements from 0.0.4.

1. A big honkin' CMS built with Syntax API technology. We'll put detailed feature lists in a separate announcement.
2. Performance: We've achieved between a 2- and 4-fold increase in speed, mainly by optimizing the base classes and adding caching to commonly-requested data.
3. Lots and lots and lots of bug fixes.
4. A revamped interface for Context, the content administration tool. It is now very stylable by CSS, has a tabbed interface for assigning privileges and sections, an export module to dump your content for each datatype automatically to Excel, an improved listing of picktables for editing, as well as an all-in-one view of approved and unapproved items, and it does not depend on JavaScript.
5. Enhancements to DBasis, including permissions for add, edit, and delete of datatypes as well as a separation of abstract datatype classes that you can safely replace when you reconfigure a datatype, leaving your user class with any encapsulated functionality intact.

1.1 (development branch)

1. Add the ability to "feature" a content object in multiple sections while leaving it unfeatured in others.
2. Event notification so you can have actions that occur when something is changed through the administrative classes.

This is tenative, but we hope to go to 1.0 publicly soon. 1.1 will be released...when it's released. We expect some point releases to 1.0 to occur as we fix bugs or release features that don't affect sites built with 1.0. If you just want the API, it's fairly easy to extract those elements from the source tree.