I was thinking more initially about just a ticket dispenser, than a session manager. It's purpose would be to assure a unique id is passed to each requestor, possibly storing some information passed to it during the request phase.
I don't see wherewas this is really a different issue, honestly.
In my particular situation I might have more than one way to manage the sessions, but would be willing to use a single session id assignment system. It may be that the difference between assignment and management collapses and I'm talking about a single management layer, but I think I'll keep them separate for the time being.
Whether it's persistent or not is a different question, but that seems to be the only different in my view.
By persistent, you are referring to the session state or the session id? [ stuff about firewalls/proxies ]
So why wouldn't XML-RPC work across HTTP? This was my option, not across some other protcol. Heck, ILU work across HTTP and I've heard of people making it work thru firewalls. XML-RPC though on thought does seem like a good option, since it's standards based, and relatively light-weight.
About the only thing I'm confident these days working across the myriad kinds firewalls (and what passes for firewalls) are: http, ftp, telnet (though usually disabled if the administrator has any authority) and (usually) ssl. Stating that a particular protocol runs on top of http isn't an automatic guarantee that it will work across http proxies. Visigenic's Visibroker fails (although I had to set up a demonstration to convince them) on their client-side http tunneling. People who have gotten ILU to work across firewalls may have had more success than I, apparently. My experiences are also about 12 months dated. I don't doubt that any given protocol (e.g iiop) can be made to work across any given firewall, but I don't have the time or resources to concentrate on this effort -- if any applications are to ever get written. ;-) All this may be water under the bridge, given your useful followup message to Mike Pelletier.
my comment was directed to the server->session-server communications.
This being the case, my comments regarding firewall issues are hardly relevant. --- interlude --- Long-term, I'm not comfortable with making distinctions between clients (where a client is always assumed to be a browser) and servers, except as roles that distributed objects adopt at different times. xml-rpc may offer some interesting ways to address these issues. My own (limited) experience suggests that it may require some effort before objects can easily communicate across firewalls. I welcome anyone else's thoughts on this subject. Disclaimer: I am not a firewall/security/network protocol specialist. Please feel free to view all comments above with suspicion or even outright disbelief. Best regards, Jeff Bauer Rubicon, Inc.