Symphony.

I am curious what you might think of the idea for workspace autodiscovery: to create/edit/delete, etc., in the workspace folder and have the changes reflected in the administration. There are certain areas (like the Utilities) that you guys already autodiscover -- or continuously load. But I suppose the better part of this suggestion is the inline settings/configuration that would be autodiscovered by Symphony and reflected in the backend (as well as updated in the MySQL -- or perhaps no longer necessary?).

The settings can be inlined with the rest of the data with a special namespace?

Example (from System Navigation Ensemble 0.1.8) workspace/pages/system.xsl

Additional information would be needed to maintain state, for example: modified timestamp per folder.

Obviously the idea is premature and needs more development, but there could be some advantageous. The first is usability and, perhaps, second is performance: reducing SQL queries?

Edit: Additionally, one would imagine that the display of the page in Symphony would filter the configuration elements since it would be redundant. But I changes in done Symphony would have to reflect in the file -- interesting.

I completely sympathise with you about how cool an idea this sounds, but on the other hand I can't think of a single reason why it would be useful. The two you mention, usability and performance, are actually reasons why we chose the DB-centric approach instead.

A while ago we'd hoped to make admin-less changes like workspace swapping more seamless, but this turned out not to be feasible. Even if the workspace is informationally encapsulated, there's no guarantee that "Publish" data matches up between swaps, unless all of that data was itself also contained in the workspace directory. (We briefly considered forgoing DB storage completely for a file system-based approach, but decided the sacrifice to performance, reliability and scalability isn't worth the quasi-useful benefit of workspace-swapping.)

There's no intelligent way to warn about errors or incompatibilities introduced by external changes, so allowing for this is effectively equivalent to allowing people to arbitrarily modify their DB, which is already possible.