Georg Acher wrote: > I also don't think that a vdr-repository would help in the development > speed. Either the whole development procedure needs to be changed (more > maintainer with KLS's approval) or it has no advantage compared to the > .tgz-distribution. > > But I think the repository stuff is only marginal. The design itself > matters. When looking at the experiences at Reel, there are some things to > be considered in the (far) future of vdr 2.0: > > - vdr has grown/evolved since 2000, but is still based in its design on the FF > card and its capabilities. There are now different signal source setups > (LNBs, rotor, multiproto, mixed tuners or shared tuners/CAMs like in the > NetCeiver, and not forgetting the IPTV variants), various output types and > devices (FF, DXR3, HDE, X11, ...) and especially more expectations what a > PC-based STB should be able to do (playback of other media, "home > automatisation", etc.). > > - It allows no real server/client distinction. It is quite common to have a > real file server somewhere in the house, but it's hard to get a vdr running > on it and viewing on other clients. Even the recordings sharing of two vdrs > is not that easy (touch update here and there...). One of the main > advantages of Unix was resource sharing and distribution in heterogenous > networks (like X over network), but vdr is currently focused only on "its" > platform. > > - The current plugin concept allows only a very limited access or > modfications in the core behaviour. At least without core patches... > > - Based on the long evolution history, vdr IMO also has some design > problems. Every object interacts with each other, I'm personally lost in the > inheritance-graph of dozens of identically named > Get/Put/Add/Del/Action/Process-calls. Also the main loop (almost 1500LOC) is > a bit fat ;-) This makes it hard for newcomers and potential contributors. I > guess that there are only very few people that actually know what is going > on in the device/devbdevice/remux/libsi-core. > > I still favour vdr over mythTV or MCE, because their neglect the TV side. > But we have to face it: Radio is dying already. Old fashioned TV over > antenna is also getting more and more unimportant and is merged with other > data sources (IPTV, internet radio, podcasts, ...). Full convergence is no > "if", it's a "when". > > So, the main discussion topic should be: What is needed for a future-proof > design? It is not about XML or SQL or other hype buzzwords, it's about the > overall design and how individual modules/plugins interact with each other. > > Just my EUR0.01... Indeed this would be a very interesting discussion. CU Oliver -- ---------------------------------------------------------------- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ ---------------------------------------------------------------- _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
