1. I feel good about finally recognising the concept of defining system privileges based on user groups, overall—but not quite so good about having picked up the idea while staring at the users and groups management console on a Windows Server 2008 machine. Why couldn't it have been something noble and inspiring, like OpenVMS, DD-WRT, or a TS-7200 NetBSD toaster? What a sad world.

Implementation of all the details is taking some time, and in the process I may have inadvertently given anonymous users the power to leave broken comments on abstract news articles, but this finally gives me a means of adding restrictions like who can create pages with parent = 0, getting rid of the arbitrary UID = 1 or 2 rule for unfettered Lists access, and even a way to explicitly assign group memberships such that anonymous can be explicitly added as having rights to comment on a specific entry. Since user 0 doesn't have a record, this was somewhat hard before.

However, it does leave some fringe cases unmanaged. User profiles, for one, only make sense as orphaned articles (an orphan is an article with parent = 0, though really this is a bad choice of name since Cadre currently lacks mechanisms to deal with pages that have deleted parents—maybe "stray"? I should just rename the global variable) and users need a way to create those.

2. I'm thinking that, like the MUE of yesteryear, there's going to come a point at which I need to design a tool that functions as the user's advocate. It will probably be in-system, which will mean it'll consist of several scripts and require robust function of exec=1 and exec=2 in order to give users limited, circumstantial access to powers normally beyond them (especially setting up their user profile).

3. All this talk about user profiles and people other than me logging in to Cadre is making me want to implement that mail system...

4. On a performance-related note, the slowdown on large lists is starting to become palpable, not in the least because we now have lists that are actually long enough to require extended thought. The Lilitic Dictionary, like a blog, is a serious CPU hog. My guess is that the majority of the resources are being consumed by constantly loading and parsing the same templates over and over again. I'm proud it took this long to develop a noticeable lag (on pass3, Leaflet, or Piki, the slowdown would have been immediately obvious!) but I know I can do better. At least for a session's duration, Octavia needs to start caching treeified templates. It'll need a single array, indexed by entry id and substring starting index. Off that hang the parsed trees that executive() calls $lines.

5. Unrelatedly, I need a way to suppress recognition of square brackets. Paralogue finally recognises and parses in-line <script> tags, and it's absurd that my choice of script block notation crashes page loading whenever an executable page or template contains JS with array subscripts. I need some kind of suppress-all-magic-and-just-print-it-you-cowards syntax; suspicious eyes fall on [ and !] as a kind of atrophied tribute to the humble HTML comment. Of course, this is bad for dreams of a unary not operator... Maybe I should just admit that Octavia is not a C language and be done with it. Or I could change that "not" into a "not yet" and remain veiled in my own imaginings...

6. A language doesn't really have to be C-like to be successful, but it helps. It also helps to not have naïve right-to-left order-of-operations handling like the least-favourite stepchild of Smalltalk, but I'm actually not sure how to implement that in Octavia's parser pre-emptively. It sounds like it requires another intermediate representation (Octavia currently ignores parentheses and just uses a ragged list for the final format—in fact, a(b, c) is just syntactic sugar for a((b) (c)), now that I think about it!) and I'm a little wary of the time required to do so. A back-of-the-napkin problem waiting to happen, at the very least.

7. Cadre can't store complex data structures very well. getv() and putv() are very inefficient. For best results, add a table, which contains just the columns "entry", "name", and "value", and use this to store extended data for an entry instead of cramming it into the body field. The result will be more readily searchable and manipulable.

People at TDWTF might laugh and call this Tableception—though I'm not very fond of the –ception suffix—and be rightly annoyed. However, writing this flexible code would be a lot simpler than writing code that handles a different case for each template type dreamt up by the users, especially when the tables are potentially extremely diverse. Whether or not SQL syntax makes this easy to implement has yet to be seen; I'm guessing I'll be doing some kind of array rotation in PHP in order to work with the values efficiently. On the plus side, I will be able to sort arbitrarily; one simply needs to know the correct columns in advance.