>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.
Got that, thanks for the explaination.
>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.
I am working on a very big project (has about 30000 requests a day)! A
lot of the functionality are different settings that the user can make
in a 4-5 steps request (in the last step the user can decide to cancel
the entire operation or at step 3 he simply gets out of the step-by-step
setting process). So I cannot just hold these objects in session
forever, that's why I think a session mantaining functionality is
required:
1. have a configuration file that specifies exactly what objects
can be hold in session
2. for each object that can be hold in session, specify the
url-patterns for which the object must still be in the session
3. have a filter that mantains the session accordingly
Emilia
-----Original Message-----
From: Samere, Adam J [mailto:[EMAIL PROTECTED]
Sent: vrijdag 9 juni 2006 15:20
To: Struts Users Mailing List
Subject: RE: best way to send parameters through more requests
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
