Vtunerc and software acceptance politics

With regards to the VDR issue: As far as I know Klaus (the primary VDR developer) only said that he won't implement a server-client architecture for VDR. (And that he probably won't be able to do support for the implementation someone else might have done).
And to be honest: As much as I like the VDR way (the GUI, the way recordings can be programmed with vdradmin and the like,...), I really grew to like mythtv at home. Apart from two "HTPCs" (actually both ION2 based diskless clients booting of our router/firewall/homeserver), we can also watch TV on our desktops,...

Anyhow, the vtunerc approach has its drawbacks, there is no point denying that, but the technical points brought up in the discussion were at least in part ridiculous (like wanting to use a DVB device on the other side of the planet, via network), or also connected with other setups (USB DVB devices for example - in the case of sudden disconnection and also in the case of possible bandwidth problems).
Ob the political side, I think the argument of "bad" companies implementing drivers via vtunerc is taken far to serious. With the same argument, we should remove tun/tap from the kernel, because that could be used by network equipment manufacturers to implement drivers for their hardware in userspace instead of kernel modules. And, if what vtunerc does can also be achieved with CUSE, why is CUSE in the kernel, it could be used to implement.....
There are also arguments against vtunerc which are valid: It would introduce a new ABI (or at least extend an existing ABI) which would probably need to be kept basically forever.
And I personally think that distributing vtunerc as a bundle of the userspace component and the kernel module source makes more sense: If the userspace interface of the vtunerc kernel module needs to be changed, it can be changed in both parts simultaneously. On the other hand, if the kernel side interface of the module needs changes, it is "a bit" more complex (you probably need to keep all used kernel side interfaces in the source, unless you only want to support a very specific range of kernel versions).

A nice library that takes most of the DVB stuff into its hands and introduces network capabilities on the go would be good anyhow. What I would love to have was some way to provide a pool of DVB devices on various hosts as the source, with the library automatically picking the most suitable one (i.e. take an in-use tuner if it already listens to the requested multiplexer and if it doesn't have more than X channels tuned to already, most PCI-DVB cards can easily be used to stream three channels at the same time).