Developing a Cadre-based project has led to a number of worthwhile discoveries regarding Cadre's maturity, its strengths, and its weaknesses.

1. The security mechanisms may not be perfectly developed, but at this point with smart use of permissions and restrictively-designed templates, it's possible to build a site that has no visible sharp edges.

2. Creating a new database is still a bit of a pain. I really, really need to write a program to take care of that sort of thing on its own.

3. Documentation of Octavia functions is still obviously completely necessary.

4. Calling template modes from other pages using page() is a drag, but it's made much worse by a lack of parameter passing. While I haven't run into a situation where parameter passing has been strictly necessary, I fear that one of these days I'll find myself writing templates that have accessor functions for every possible getv() parameter, with execution that bounces back between the two pages mindlessly in order to get a simple task done. This is obviously insufficient.

5. children() and index() aren't sufficiently powerful tools for performing metrics on other pages. Querying achievement instance counts in Prospectus is possible using them, but would be extremely inefficient without parameter-bearing page() fetches. I've implemented search() (a LIKE for any one specified field) and locate() (a = for any one specified field) as a step toward rectifying this.

6. Retaining architectural support for non-SQL storage mechanisms will probably ultimately require me to implement an entire database engine in Cadre. This is obviously undesirable and I should just start implementing fancier commands.

7. Normalizing the getv()/putv() system will become necessary the moment I want to sort by more than one v-field. Which will probably be sooner rather than later.

8. The more I use them, the more I find a custom-tailored solution almost always fits the job much better. Consider this blog post, for example: it will appear on the entries list, blank, until I actually hit the "post" button. In almost every case where I've set out to use an abstract list—PCMNET achievements, badges, characters, users, and trouble tickets; Cyto Task Management; Thessian dictionaries...—they've been imperfect. They only really persist in news systems and checklists, where they're both not quite right. Blarg!

9. I'm in a funk right now because I'm pretty sure Octavia should be transparently object-oriented. Worse still, I want to replace traditional getv/putv with a table of associated fields (entry id, field name, data) so they can be searchable. On the plus side, these can probably both be implemented as extensions to the current architecture without disrupting the current system. Associated fields would be equivalent to persistent, primitive variables attached to an entry, which would in turn be equivalent to an object. I guess it's a bloody good thing I put all those dollar-sign sigils on standard variables.