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 modularization. Additionally the modules should be grouped by layers, which makes design cleaner. > 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 different/independent state. 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 number 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 recording. 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 fallback. 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 Gero _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
