Chris Foote wrote: > Is maintaining the list of objects on the server for each client a real > resource problem ?
Well, it could be, and I say could because at the moment I have no session state to maintain. If I keep it this way, or I recover the session completely from client supplied data, then I could achieve naff things like not having to time out session data on the server due to clients disappearing (and thus making arbitrary decisions about what constitutes client "liveliness"), and load balancing amongst a set of servers without having to replicate the session between them because the client provides it. A client could come back after a year, and provided the underlying result set hadn't changed still be able to pick up their iteration from where they left off. I've found that Microsoft are doing a similar thing under ASP; if you have a look at the Foxtel TV guide page you'll find a hidden form variable called "__VIEWSTATE" with a honking long base64 encoded string, which is apparently the session state serialised and passed to the client for safe keeping so that the server doesn't have to maintain it. > If not, and if your desired outcome as you say is: > "my goal in the first place was to lazy evaluate the list so it > wasn't pulled across the link in its entirety" I should have written "a goal"; I'm just envisioning that lazy evaluation will naturally fall out of this scheme, and the client having the placeholder so it can tell the server "btw, this is where you got up to in the list you were iterating for me". I've seen some indication that currying functions might provide me with a solution for what I'm looking for, so I'm currently trying to wrap my head around that. > e.g. If you created a server XMLRPC method customers.getsome(limit=1) > and get the client to manage loading of the data via a seperate thread > where it puts items from the list into a queue[1], then you could watch > the size of the queue and call customers.getsome(limit=50) in advance > of the queue being empty. If the client doesn't need all of the data, > it just needs to toggle a flag on the queue loader to not bother calling > customers.getsome() anymore. Yep, that should also just naturally fall out of this, once I've got a working solution of what "this" actually is. :-) Pre-emptive lazy loading ... I think I've bored everyone witless for now; I'm off to cut code ... Cheers. -- Regards, Daryl Tester, IOCANE Pty. Ltd. _______________________________________________ sapug mailing list [email protected] http://mail.python.org/mailman/listinfo/sapug
