[sapug] Stateless Iteration
Daryl.Tester at iocane.com.au
Tue Jun 13 13:51:55 CEST 2006
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, 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 ...
Daryl Tester, IOCANE Pty. Ltd.
More information about the sapug