I have started another thread about using variables in the request string and storing them as a variable. Any Ideas? -----Original Message----- From: Christopher G. Petrilli [mailto:petrilli@amber.org] Sent: Wednesday, February 24, 1999 2:09 PM To: zope@zope.org Cc: jbauer@rubic.com Subject: Re: [Zope] Preserving Settings during a user's session On Wed, Feb 24, 1999 at 01:58:14PM -0600, Jeff Bauer wrote:

...

...

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.

Maybe we're crossing wires, but I think we're talking about the same thing here... basically your "ticket" is my "sessionID" we then get into the discussion of whether or not this information is persistent across time (and if so, how much). Obviously this information must be persistant across SOME value of time for it to be of any value. The question for me is whether or not this piece of information should bring with ti OTHER information referenced with the sessionID as an index. Hmm, how to explain this :-)

...

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?

They are implicitely the same... a "session state" is just an object associated with a specific session ID.

[ stuff about firewalls/proxies ]

Now this is just handwaving at this point, but XML-RPC is just a new mime-type, nothing more. So as long as your firewall doesn't filter based on mime-type, or allows you to determine which ones... you should be OK. This would be no different than filtering based on image/gif, or something along that lines. I believe the MIMe type in question is text/xml.

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.

I agree, but for the foreseeble future, my crystal ball says HTTP/HTML will continue to dominate the client/server level... what is more interesting from a Zope perspective is teh server/server middle tier, which will probably move toward a combination of CORBA and XML. Chris -- | Christopher Petrilli ``Television is bubble-gum for | petrilli@amber.org the mind.''-Frank Lloyd Wright _______________________________________________ Zope maillist - Zope@zope.org http://www.zope.org/mailman/listinfo/zope