Alex's dashboard

I expect other developers with a decent amount of experience agree COM is the way forward. It does everything we need, it's well understood, used and supported (also still good for legacy apps and apps with custom scripting languages).

To those suggesting an in-built web server, let me propose another view: the last thing we need is yet another application providing its own dodgy web-interface when it's not being accessed *over the web*. We don't need the bloat (it's virtually guaranteed to be less efficient than a proper local IPC system), we don't need yet another udp or tcp port taken up and we don't need yet another trivially target-able avenue for exploits (even if it only binds to localhost). I wouldn't mind this being an optional system - e.g. some preference to "Enable local web interface" or such, but it should not be on by default and should probably require SSL and authentication too. (Hint: dodgy javascript, firefox bugs, IE bugs etc. can be exploited to attack "local" web servers.)

Regarding .NET: it makes interaction difficult from any other development environment than Visual Studio and, frankly, .NET's IPC is dodgy at best. The concept was fine, the implementation was shockingly bad. Things are better if (and only if) your target application was made for .NET 2.0 and later - and thats still flaky. Also, keep in mind users will then be forced to have the .NET Framework for applications to use use the interface (or at least some of the redist dlls) - sometimes this is simply not an option. Or does Spotify require .NET?