Am 01.03.2012 06:37, schrieb Gero: >> 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? You got me wrong on that. My vision would be that timer UI and recording backend are two modules, and in a more complex environment there may be several UI frontends connected to one (or more?) recording backends. Any client should be able to edit timers on the server independently, the backend shouldn't even have any UI. In fact, any UI should be located in the frontend. For all sxfe fans: A frontend implementation itself could split into two parts, one server-side frontend, and one lightweight stream&OSD display. Or keep latency low and put a more complex frontend on the client, that acts independently of the server backend. A high-level frontend could connect to one or more receiver backends to get channels on demand, would be able to schedule timers on recording backend(s), and would be able to play back from storage sources. Why not allow a storage plugin to act as a media player instead of just VDR recording server? Or on-the-fly transcoding on 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. Thought of that. Generally, the default link between video frontend and receiver backend should be handled like transfer mode, to make things more unique. For the case of FF cards, there could be an additional prefer-this-backend-for-this-frontend rule, and a shortcut in transfer control that routes the video stream within the card instead of user space. > 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. Well, I have a different vision: More like recording server and streaming client, where all the UI logic resides in the client, and the server doesn't need to know about UI at all. One advantage: Allow a frontend to connect to more than one backend. For example, have two 'full' VDR systems with receivers, recording capabilities and storage, and some streaming clients. And then let each of them use any receiver, any recording capability, and any recording storage that is available. As said, the server itself could spawn several clients, so sxfe-like lightweight viewers can connect to it. There could also be shortcuts if backends are on the same machine or in the same executable, so not everything must go over network. However, thats all pretty much vision and far from being reality. Cheers, Udo _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
