On Wednesday 29 February 2012 - 20:45:54, Udo Richter wrote:
> Am 29.02.2012 17:50, schrieb Tony Houghton:
> > For better client-server VDR needs to support multiple clients watching
> > different channels with different OSDs simultaneously.
> Not necessarily. I think the key solution is to modularize VDR's
> internal structures, with well defined interfaces between them.

Well, that task is overdue, but not necessary to provide real a C/S app.
But I think, the C/S task is easier to workout after a complete redesign and 
Additionally the modules should be grouped by layers, which makes design 

> A timer menu that belongs to a recording backend, a recording menu that
> displays content of storage modules, several frontends that can connect
> to one recording backend or several storage modules, ...

I think, here is already the first shortcoming in design. May be cause you're 
thinking with today plugins in mind?
If several independent clients open a timer menu, they should not interfere 
each other. If the menu is tied to the recording module (which should be a 
singleton), timer-menu would be like a singleton and a keystroke of one client 
changes the menu of all other clients too. That's not desired.

Therefore menu representation should be decoupled from menu data, so i.e. the 
recording module (as all backend modules) provides their data (the timer-list) 
as list or tree structure only. 

The vdr provides a menu for each client, which is based on the same 
(singleton) list of timers.
This way, each client can operate independently and if one client changes a 
timer, every other client will see the change - but no client is disturbed by 
the actions of other clients.

So from my point of view, future design will have different types of plugins, 
like backend- and frontend-plugin (or name the plugin templates by the layer 
they belong to). They might have the same interface, but I think, it is better 
to differ the interfaces, so a plugin cannot be misused by accident.
So backend-plugin (like nowadays dvdswitch) will only be allowed to provide a 
list of items, which will be used by OSD-Providers, that will create a menu 
different for each client and of cause, each menu can have 
For configuration a backend module may only say, I need an integer value called 
"value", ranged from 0 to 5 with default of 2 - and it is up to the OSD-
painter (skin), whether to use a slider or an input field, or what ever ...
The backend module should not be allowed to care about user input elements.

Thinking about configuration, the backend should be able to configure the 
of possible clients and so the open ports.

When a client connects, the vdr looks for a free input-module, that serves 
life-stream. Having multiple independent clients, the command to change the 
channel should not have any side-effect to other clients, nor disturb an active 

Additionally it should be possible to configure the preferred input device used 
by this client for life-view. Other devices may be configured as fallback, in 
case the preferred device is not available.
For FF-clients it is evident to have a preferred input device without any 
I think, this way no further distinction between FF-client and other clients 
is necessary.
> With defined and pluggable structures between them, its easy to have
> them either locally connected or linked over network. Whether that's
> done by a plugin or VDR internally doesn't matter.

Oh - I think it does matter!

As I already wrote, from my point of view, plugins may continue do networking, 
but the connection between backend- and frontend-part of vdr should not be 
public nor affected by any plugin. 
And the connection does not have to be tied to networking. Networking is just 
one implementation of internal communication, which could easily replaced by a 
communication, that uses shared memory or pipes or what ever - if backend and 
frontend reside at the same machine.
So modules of internal connection may be interchangeable, but they should be 
considered private to vdr-core.

Don't know, whether it makes sense to look a existing C/S protocols. If I got 
it right, there's no standard for it and each plugin uses its own protocol. 
C/S networking needs one channel for streaming from server to client and one 
channel for commands from client to server. 
This 2-channel networking is standard for any networking, so I don't see, 
where networking is a challenge. It might be the smallest and easiest part of 
the redesign.

Real challenge is the break down and distribution of responsibility.

> In any case this would be the biggest rewrite of major parts of VDR
> ever, with lots of breakage, total loss of plugin compatibility and very
> long development cycle.

:) so the earlier this task starts, the earlier it may finish :)

kind regards


vdr mailing list

Reply via email to