Muchisimas Gracias tj!
Following lots of thoughts, here's an update on the plan so far:
To completley decouple the presentation from the functionality, and working on local network ports to get the two to communicate. it will be an asynchronous event model which is slightly harder to code, but but it does mean that ANY presentation technology can be used (flash/web page/custom code).
The backend will be like a webservice that exposes it's functionality, and uses plugins to wrap other api's, such as speech/telephony/multimedia. The plugins will be installable by simple installers (every plugin will register it self when it installs).
There will be heavy emphasis on the UI being driver friendly and doing things with minimal interaction. I'm trying to think of scenarios like: "this song should be in another playlist so I want to move it, and the system should give me the most probable targets"
The framework will be generic enough to be compiled to any platform supporting .net, but the plugins will be heavily wWndows biased, since Microsoft include a lot of API's like speech, telephony etc. perhaps if there is interest, the developer guide will allow others to write specific plugins to support other platforms. but this is not planned out of the box.
All configuration will be wizard based, and a generic configuration framework will be used throughout the app for consistancy. When a plugin installes, it will use this framework to allow the user to configure it.
Any comments or suggestions would be much appreciated.