Roadmap

MySQL

• Dealing with transactions. It's safer and, if used right, faster. We need to change Solstice::DB to handle transactions for this.

This really turns out to be tricky. It's easy enough to add begin/commit/rollback to Sol:DB, but what happens if you begin a transaction and never commit it? Should handler call rollback programmatically? that will revert user session changes and log entries and so forth. Pretty scary. Having handler auto commit it might be better, but could unknowingly commit the bad data that caused the error in the first place. Maybe we should wait for MySQL's new transactional database before we put time into this.

Wishlist

Additional or improved behavior of a lower priority.

Adding transition options to post click controllers

With some navigation schemes, such as having a set of radio buttons that determine what action a user should take, our current pageflow system isn't as flexible as it should be.

Status Info

We've started using a 'Status' table informally to hold status info about the installation - we should create a well-written API for working with that table.

For instance, items of status should be tagged with process ids or maybe the status tables should be done with transactions or db locks or something or.

Streamlined Application Installer

Whether we do something interactive or just make Solstice handle more of the (already few) steps is to-be-decided. But this process should be easier.

Tighter model/db integration

We should look into a Class::DBIx (or whatever the good one is) Solstice::Model superclass, along the line of the freezer superclass, tied in with centralized factory?

Alternate Logins

Make it so alternate login methods can be used, instead of relying on apache modules for auth.

Potential Model Improvements

We like some of the things we see in Moose so:

• Default values: It would be nice to specify that an accessor was required to return a value, and specify a default if nothing had been set. This could be done as a string or a sub, perhaps.
• Coerce values into typed accessors: make it possible to pass any Solstice::DateTime compatible string into a datetime accessor and be turned into a DateTime object, for instance.
• Custom constraints: having a datatype is nice, but adding customizable validation to ensure more specific values would be good.

More Flexible Language Files

A tighter relationship between the language file and templates would be nice, including the use of template logic in lang strings.