Jason Tackaberry wrote: > I can add authentication. But the data still wouldn't be encrypted, so > in any case this solution isn't suitable for use over a public network.
I'm not taking about encryption. Just make sure nothing from the bad bad outside can connect to the server. E.g. yuo have something running on a socket at port x and you don't have a firewall, everyone can connect to this port and do nasty stuff. So authentication is all we need and we don't need it for unix domain sockets. > But for purposes of epg and vfs, I agree with your basic architecture > of: database on local machine, db reads in thread, db writes over ipc. > For something like managing recording schedules in kaa.record, a simple > authentication mechanism in kaa.base.ipc might do. Good. >> local. We also can't use mbus because it is designed to be a message >> bus, not a bus to transport that much data (but it is secure btw). > > mbus is secure, is it? High praise indeed. I wouldn't use that word > about any software. :) Even about openvpn, which could be the best > piece of software I use on my computer. OK, it is secure enough. mbus has authentication and encryption, pymbus only has authentication but that is enough. There is a small hash at the beginning of the message. And the mbus is always link local, so you can't do much damage from the outside. >> (async). The thread will not only query the db, it will also create >> nice 'Program' objects so the main thread can use it without creating >> something. There should also be a cache to speed up stuff by not using >> the thread with db lookup at all. > > Herein lies the main benefit of doing reads in a thread. The thread can > also take care of putting the data in a manageable form for the main > application. This is important particularly since Python is a hog when > it comes to object creation. Yes >> Freevo knows what channels would be visible when entering the tv >> grid. So Freevo will request these channels with programs +- 6 hours >> at startup. > > Using my rewrite of kaa.epg (which I've cleverly called kaa.epg2 for > now), this takes 0.2 seconds and returns 1978 program objects. Freevo won't need that much data. The program guide can only show 10 channels (or similar). So we only need the data from that channels which is very quick, even without caching. > BTW, when parsing my 17MB xmltv file, kaa.epg takes 74 minutes ([EMAIL > PROTECTED] > $!#@) to execute, and uses 377MB RSS. My rewrite (whose improvement is > mainly due to my use of libxml2, of course) takes 94 seconds and uses > less than half that memory. And I guess we can make it use less memory. We don't need to read the xml file and store it to the db later. We can read one item in the xml file, add/check it against the db and remove it from memory. > That's a 50X performance improvement. I guess we need to replace all xml code in Freevo to use libxml2. >> And kaa.epg has different sources. One is >> xmltv, a new one could be sync-from-other-db. > > As I mentioned on IRC, unless this is just a straight copy of the sqlite > file, this probably isn't worth it. Syncing individual rows means > accessing the db through pysqlite in which case we're not really saving > anything. With libxml2, parsing the xml file is very quick. Almost all > the time is due to db accesses, so we're not saving much by syncing at > the row level from another db. But maybe we use the epg in the dvb stream. > Copying the epgdb.sqlite file straight over would be a big win, of > course. We could implement that eventually. But I guess you need to disconnect from the db before doing that. Dischi -- Please do not complain about the coffee. You'll be old and weak someday, too!
pgprEQAhUXRpe.pgp
Description: PGP signature
