All of the choices in this discussion could become equally available options if the LMCE architecture were properly 3-tiered.
All of the data, including system config, should be in the database, even if there's a lower level for interfacing the database to the OS config files. Databases bring a lot more to the architecture than just data storage, including clustering for reliability, easier data conversion (like upgrading), statistics, config scenarios, and most important a consistent data API for all data, even as middleware. A proper data tier would be a LMCE API to the data, independent of the RDBMS used (ie. MySQL, Postgres, Oracle). Especially for installing in environments that already have an RDBMS running, this is the best data architecture.
LMCE is mostly independent apps glued together to deliver combined features to a unified user experience. The DCErouter does a great job of abstracting all the messaging and kinds of apps. What it could use would be abstraction of its interface to the data and UI APIs, to go with their own modularity.
The UI of course will "sell" LMCE to the mass audience against other competition like WMCE, and Apple's and Sony's inevitable products. Even if the other systems have much less function, even with crippling DRM and other closed (even arbitrary) constraints, people will prefer them if they looks like what they want. LMCE should have a single GUI definition that is rendered differently for dedicated devices (like the Orbiter) and for Web access (eg. remote access or as webservices). Orbiter should read an XML file that defines the skin, links to other fields, and to executables. LMCE's webserver should render that XML file as HTML and glue it to the executables, preferably as AJAX. Functions should not be segregated between Orbiter and webpages, requiring both users to use both GUIs for a use case requiring both segregated functions (like configuring disc ripping storage format, then starting the ripping), and also developers to work redundantly in both segregated presentation code files - with different appearance in each.
Organizing LMCE into that architecture lets its components operate and get developed independently, with core and optional features. That architecture lends itself to deployment as .deb packages, which can just require all the standard external packages of Kubuntu and other apps (ie. MythTV, MySQL, etc). The LMCE project can use those packages to offer a custom distro ISO with all those packages for convenience, preferably a net installer against the existing external repos and an LMCE repo for just the LMCE-specific meta/packages. Especially as Ubuntu upgrades every 6 months, LMCE can just use its APT system to eliminate problems managing dependencies and the bulk of the bundled apps. While making it much easier to compose variants that use alternative components, such as different databases, custom theme GUIs, and omitting unneeded functions from either/both the GUI or/and the apps and data.
We don't have to make choices as a project that exclude some alternative LMCE configurations that would work, just to keep our work on it simple enough not to drive us crazy. The current upgrade to 0710 is a turning point that makes LMCE able to upgrade along with OS upgrades (another is just about 4 months away), as well as present a development platform that can be scaled to a larger, more open developer community. It's already modular enough as DCErouter and device templates that we're not stuck. Let's keep the architecture as open (to alternatives) as possible, wherever that openness lets making choices not actually core to LMCE be someone else's problem, in their own component project or configuration bundling.
