On Mon, 13 Dec 2010 17:58:50 +0100 Denis Loh <denis.loh@xxxxxxxxxxxxxx> wrote: > Am 12.12.2010 22:27, schrieb Eric Valette: > > On 12/12/2010 22:02, VDR User wrote: > > > >> (Btw, Klaus has made it clear VDR was never intended to be a > >> server/client system. Maybe at some point it will address that > >> need in a well-thought out way but as it stands now I'm not so > >> sure it's a good basis for argument.) > > > > On the other hand, with streamdev server, vnsi server, we are > > approaching the client server mode. > > > > I think the real question for selecting a database are: > > 1) do I need a SQL interface, > > 2) do I need a client server model, > > > > sqlite is in use in 200MHZ mips router/ Tokyo/Kyoto cabinet can do > > less but consume even less. > I was wondering why it must be a SQL DB. The new VDR requires at > least one plugin namely sdff- or hdff-plugin So, defining an > interface - for instance EPGProvider, with a basic implementation > like the one which already exists - and let the user choose if he > requires more power and extended functions to store and query the > EPG, is a good option. Then he may install a EPGProvider plugin which > comes with a sqlite-DB. Actually, sqlite may be good enough to be > used for epg data. However I don't see it in the core. Klaus Point is (until now): - this wont go into a plugin - hand crafted database is enough My point is: - i want to have possibility for a choice with difference in behaviour/scale If i remember well the DVB devices have been planned to be plugins as well in the past - so how the cEIT scanner fits into the picture ? I dont want to put something i want down someone elses throat ... only choice. _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
