Re: [OT]: POST/GET semantics
At 10:45 11.04.2001 -0700, Andrew Ho [EMAIL PROTECTED] wrote: JZI have found that having a session object is a rather bad idea. What JZhappens if there is such a beast is essentially communication of JZfunctions through global variables. So I thought about the cure and JZfound that having server side "objects" that can be retrieved through an JZid enables "passing of parameters by reference". The client does a JZrequest and gets an id with the response, which he will return to the JZserver with further requests to refer to an object created with the JZfirst request. What you describe is exactly, I think, what most people think of when they talk about a session object. The client must always somehow indicate who they are, so you know what session to associate them with. No. I have found that having a session object creates maintenance problems. People start to pass things on the server side. Pages depend on a certain order of calling to work properly. Pretty soon the session object holds 30 properties (or however you call them). Noboby knows what they do, nobody knows why they are there. The (anti-)pattern for this is "communication of functions through global variables". So what I want is replace the session object by multiple objects that are refered to by ids that are _explicitely_ passed as parameters. This looks exactly like "passing parameters by reference". In general I think that people are pretty much obscured by objects. Things get pretty straight forward if I think of HTTP requests as function calls. Joachim -- "... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden koennen."- Bertolt Brecht - Leben des Galilei
[OT]: POST/GET semantics
Hi. I have found that having a session object is a rather bad idea. What happens if there is such a beast is essentially communication of functions through global variables. So I thought about the cure and found that having server side "objects" that can be retrieved through an id enables "passing of parameters by reference". The client does a request and gets an id with the response, which he will return to the server with further requests to refer to an object created with the first request. The question however is: If I create an object on the server that is only accessible to the requesting client (the id can be thaught of as a password) - may this be done with a GET request? RFC 2616 says that the idea of GET is that the client can not be held accountable for the side effects of GET. If I however return an id to the client so that only this client has access to the effects of the request this client is in full control. An application for this would be to have a request that creates a result set for an expensive search and returns an id to this. Any comments appreciated, Joachim Is there a better place to discuss such a question? -- "... ein Geschlecht erfinderischer Zwerge, die fuer alles gemietet werden koennen."- Bertolt Brecht - Leben des Galilei
Re: [OT]: POST/GET semantics
Hello, JZI have found that having a session object is a rather bad idea. What JZhappens if there is such a beast is essentially communication of JZfunctions through global variables. So I thought about the cure and JZfound that having server side "objects" that can be retrieved through an JZid enables "passing of parameters by reference". The client does a JZrequest and gets an id with the response, which he will return to the JZserver with further requests to refer to an object created with the JZfirst request. What you describe is exactly, I think, what most people think of when they talk about a session object. The client must always somehow indicate who they are, so you know what session to associate them with. JZThe question however is: If I create an object on the server that is JZonly accessible to the requesting client (the id can be thaught of as a JZpassword) - may this be done with a GET request? RFC 2616 says that the JZidea of GET is that the client can not be held accountable for the side JZeffects of GET. If I however return an id to the client so that only JZthis client has access to the effects of the request this client is in JZfull control. It can be done with either GET or POST. However, if you use GET, you have to prepare for receiving GET requests possibly more than once (although sending Cache-Control headers should minimize this). In your case, since your search application does not change any permanent server state, it's fine to use either GET or POST. Note: in HTTP, the client is ALWAYS in "full control". HTTP is always a client-pull model. Whether you use GET or POST, the client can always choose to replay a previous request. So you have to prepare to handle this case no matter what. You may want to read the chapter on server-side state in the Eagle book. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
