The thought here(base64 encode) was to store the data on the client. This would also be a large effort requiring all POST requests, making sure you always send the data in both directions, extra network etc.
Bottom line, storing state for a particular client is what the session is there for. Anything else will most likely cost more in development effort than upgrading hardware. Adam -----Original Message----- From: Dave Newton [mailto:[EMAIL PROTECTED] Sent: Friday, June 09, 2006 9:06 AM To: Struts Users Mailing List Subject: Re: best way to send parameters through more requests Emilia Ipate wrote: > Now the question comes: when does the object come useless? It is > useless when users gets to step 5 and also when from a middle step > (like 3) decides to get out of the this 5 step request-chain. In both > cases, the object should be removed from session. I would say to have > a configuration file that says for which url-patterns request should > the object be kept in the session. So, when another request (which is > not part of the url-patterns) comes in, the filter will remove the > object from session! > > What do you think? I think that's not worth the effort. > What else I could do to make sure the session does not become too big? > Encode64 sounded like a good idea. > Huh? That would make binary data _bigger_, not smaller, unless you then zipped it, which seems... silly. Dave --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ----------------------------------------- The information contained in this message may be privileged, confidential, and protected from disclosure. If the reader of this message is not the intended recipient, or any employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Paychex, Inc. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
