[eluser]jv2222[/eluser]
[quote author="jedd" date="1261032004"]
Well, you're ahead of me then.
I still don't know what
the issue actually is (or was).[/quote]
Well from my brief sojourn into CI sessions, I think what mrbinky3000 was trying to say was...
Quote:Since native PHP sessions already deal with retaining a state-machine between client & server... and since there are already a number of tools that deal with scaling PHP native sessions... and since general session functionality is essentially a state-machine type issue, why replicate it within the CI framework.
So, I see that your argument is essentially
Quote:CI framework sessions let you do more because you can select multiple rows from the db and deal with stale sessions etc
My argument against that would be that those are two different patterns at work and they should probably not be coupled.
The simple temporary state-machine style session data should probably be handled by native PHP sessions. Then, built on-top of that should be another permanent state session class/library that uses the DB.
It's the permanent session lib that (in my book) should be part of the CI lib - and it should extend PHP native sessions rather than override them.
There probably is already a CI lib that takes this kind of approach (I haven't looked)
It's fine the way that CI does it - although I suspect from a purest software pattern perspective it might raise a few eyebrows - but whadda they know!
Anyways, I think I may try to port my non -standard session libs into CI for my own projects cos they couple in user management which is EVEN WORSE! But it saves me time so what the heck.
