I don't think this discussion is that heated - I think we mostly agree (though talk of forking LMCE does seem inflammatory). At the risk of actually being inflammatory, I want to point out that I don't think anyone in this thread (or elsewhere AFAIK) has suggested that a consumer user should ever be deciding which app handles which task, other than perhaps when installing and picking from a list of equivalent alternatives (where that's possible). Never when in actual use getting their hands dirty on the internals. Everyone agrees (AFAICT) that LMCE should operate as an appliance.
But I do think that where there are choices between equivalent functions, like "playing WMV by either MPlayer or Xine", that choice should be exposed to the user
at install time,
with popular defaults, with all choice options tested (by the developers) to work.
I also think that other factoring, like making the Web and Orbiter UIs share as much code as possible, would make everyone's LMCE experience easier, whether developers with a simpler codebase or consumers with fewer arbitrary (and often mutually exclusive, even within a single use case path) modes. Such a factoring would do well to target using user selectable skins/themes, especially if its possible to use existing skins/themes to capitalize on market familiarity, especially if some competing project's theme is offering that competition advantages that LMCE beats under the hood. While also opening the UI work to a much broader community of people qualified to make or convert skins, who aren't as qualified to contribute to the code the skins call.
On configuration and the DB, I absolutely prefer all configs to be mediated by the DB. It makes keeping multiple scenarios available much more straightforward. It makes config UI more accessible to different user apps, without as many permissions problems. It makes configs across the network more easily programmable than editing files, modeling dependencies between components, and to their configs, in simple relations. It enables easily deploying new installs against existing configs, whether local or from a networked community, which is
one of the visionary promises of LMCE. And offers all kinds of other features that the bare filesystem doesn't (eg. scalability including factoring to a standalone but clustered network config server). The way to get what we all want is just to include a script that updates the DB when filesystem configs are changed, just like the reverse that LMCE already provides.
As for "Appliance vs Package vs Distro", the high-level topic of this thread, I don't think that's an actual choice among exclusive options, either. I think we all want LMCE to work like an appliance, to use the benefits of the package system. Eg. dead simple upgrades when Ubuntu upgrades every 6 months, easy installers that manage upgrading components like Kubuntu, MythTV, Asterisk, MySQL, etc by just wrapping their package installers, even offering LMCE kernel tweaks as packages that a LMCE metapackage depends on, that upgrades the kernel as LMCE developers specify, but which is all invisible to the consumer - except what they're not noticing is eliminated hassles.
We're waiting while 0710 takes us through a crossroads. Not just institutionalizing keeping LMCE synced to Ubuntu releases. But the product of that process will open the project to more developers, and also to more consumers. Removing these limits to scaling the project (and to scaling the installations) will help determine whether LMCE grows into a premier media environment despite competing with Microsoft, Sony and Apple, or remains a compelling hobby / cheap starting point for proprietary home automation dealers. I'd like to see it be all of those things, by being the most flexible product that doesn't confuse the consumer.
