On Tue, 2005-10-11 at 16:01 -0300, Rob Shortt wrote: > If would be good if you can add that kind of authentication. I don't > think encryption here is a big deal, we're talking LAN here.
Ok, I will add it. > in a situation where I needed encryption I'd use ipsec which is easy to > set up. True only for certain unusual definitions of "easy." :) > I think the only entry into the database should be a single process that > can be accessed through IPC or another convenient interface (only). > Now, inside this application I'm not entirely sure (or care, as long as > it works well) how it treats read / writes to the db. I agree that conceptually this is the best model. In practice, moving large datasets can be fairly costly. Some of the cost can be mitigated by keeping only fairly low level db accesses in the server and moving the data from the server to the client in as raw a form as possible (i.e. a list of tuples as opposed to a list of objects). Whether or not this will yield adequate performance depends entirely on circumstance. For example, with my epg rewrite, a local query that returns 2000 Program objects takes 0.122 seconds, whereas that same query via IPC takes more than double the time, at 0.27 seconds. If we access the unnormalized list of tuples right from kaa.base.db, the query takes 0.048 seconds locally, and 0.08 seconds over IPC. Nearly double again. However, once we move that data into Program objects on the client side the total execution time will be closer to what it would have been locally (maybe 30% slower instead of 120% slower). So, in kaa.epg's case, we could probably get away with keeping communication strictly via IPC. This is all very cursory and I'll have to run some better tests. There will always be a penalty hit when going through IPC (as opposed to a thread that reads directly from the database). We need to decide how much of a hit we're willing to swallow to adhere to the conceptually cleaner model. In practice, it may be that kaa.epg works fine here, but kaa.vfs doesn't. (kaa.vfs could be moving a lot more data.) > database / server. Will we use some callbacks for when the server updates? Yes. > Ideally I'd like to see everything done realtime, from the client, to > the server, to the database, but I'm not sure we can get the performance > there that we really want. Is it bad to dream? A small buffer on the > client and prefetching could hide potential lag. For kaa.epg, it could very well. That model might not work for kaa.vfs. Only testing will tell. Especially for a client/server situation on different computers, prefetching could be the only way to make it work acceptable. > I would be happy with something like this: What a lovely diagram. :) That does look like the nicest model we could hope for. I've updated it below to include what dischi and I were talking about: > +---------------------+ > |epg_server.py + > +---------------------+ > | kaa.epg +-------+ > | | DB |------+ > |-------------+-------+ | > |object interface/IPC | | > +---------------------+ | > /\ | > / \ | > / \ | > TCP/IP UNIX | > / \ | > / \ | > +--------------+ +--------------+ | > |epg_client.py | |epg_client.py |--+ > +--------------+ +--------------+ > | client 1 | | client n | > +--------------+ +--------------+ > | cached OR | > | realtime view| > +--------------+ Dischi and I were suggesting a connection between epg_client and DB for the case where the client and server are on the same system. It does complicate the model, but that's reality when you want to improve performance. :) In either case, that detail is abstracted by the client API. client 1 should not be coded any differently than client n. This does make the client API rather more complicated, that's easily granted. That complication might not be worth it for kaa.epg and from what I've seen so far, we probably can avoid it in this case. Jason.
signature.asc
Description: This is a digitally signed message part
