|
|
Posted by Steve on 04/24/07 14:03
| What if one were to export the session data at intervals into files, or
| overwrite a particular file at each step. The file/files being named in a
| fashion that identifies their place in a hierachy, say a combination of
| session id & time.
i think you're leaning towards 'magic' here using files with names packed
with meaning. i don't think this would do anything for you. 1) because you
can do all of this in sessions without the additional work. 2) if there is a
loss of a session, you're in the same boat as the rest of the alternatives
presented. 3) except you're using files to store the data, is that
significantly different than using another external storage
facility...like...a db?
| At the beginning of a new step, or say when there is a refresh perhaps, or
| another appropriate time, the file data is compared against the contents
the
| $_session array.
ok.
| If it's found that a step has been lost, or data is lost that can only be
| explained by some failure, assume lost data, and reload the file back into
| the session. This would effectively take the session back to a recently
| saved state.
which file goes with what client? what does the file store (i.e. social
security numbers, credit card information, a list of addresses for those
under witness protection). making the wrong decision about whose data
belongs to whom is a big deal.
| If these files were then deleted at a valid end of a session, or deleted
| after a given period of time they should not become excessive.
| If the session id and time were combined in the naming of the file then
the
| files should never be able to be retrieved accidently, thereby exposing
| sensitive data.
however, this only adds a level of complexity that needn't be there. both
proposals (sessioning data and db storing data) work just fine when sessions
are in place. jerry sees this as an equality...really, he just wanted to
take a dig at my original response to the op (whom he never even addresses
in this thread for all his ranting). the distinction i've made is that if
there is a means to accurately associate data with a client (say a user id,
questionaire id, part number, workstation id, etc.), then db storage is the
best alternative, as it can scale, you can recover from dropped sessions
with zero additional programming, you can share data concurrently with
others (viewing, editing, etc.)...none of these are options with just
sessioning data.
argument over, point made, jerry can kiss my ass.
| Of course I am new to php, and internet programming in general and likely
| have missed something in the scenario. However, it's something that
| appears, to me, to offer a possible solution the the problem as it was
| described by the OP.
| Just a thought.
i know, huh! i gave a couple of suggestions. i've seen many posts about this
before and had hoped someone would respond - as i haven't run into this
problem. jerry just wanted a venue to make a point, however he never really
made it. he don't like me much which is why that's all he addressed.
oh well.
cheers, vinnie.
Navigation:
[Reply to this message]
|