Why would you use CI session class over php sessions?

[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...

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

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.

[eluser]jedd[/eluser]
AFAICT mybinky3000's problem was that they didn't work at all. After much prodding he eventually deigned to provide a walk-through on how to reproduce his problem. I spent a couple of hours setting up a test environment and trying different variations of his instructions, but could never get the error(s) that he did. I observed as much in whatever thread, at the time, and haven't heard back since. Consequently I, too, can only speculate at the true nature of his problem.

I think you may be misquoting me.

Remembering that it's been some years since I used native PHP sessions - I think the big benefits of CI sessions are that a) you can easily encrypt them (ie. Security), and b) you can easily store them in a database (ie. Security and removal of Cookie size limitations). The 4KB limit removal is probably very appealing to many developers.

While a side-benefit of the database storage is that you can then do things across the set of session data (that you could not conveniently do otherwise) I don't see this as the primary feature. But, since I'm not really a power user of this stuff, perhaps other people do. As an aside, I have no idea how you could build 'on top of native PHP session's' any kind of database store - short of having this done on every page load, of course, which then leads you ineluctably back to doing it in your framework .... five minutes of casual design pondering later and you're back at the CI way of doing it.

Your argument - separating two patterns - is understood, but perhaps comes down to how the developer uses the feature, rather than the nature of the feature proper.

I haven't heard any compelling reason for using the native PHP sessions (other than to save some people some eyebrow exercise

But, equally, I'm not really a cookie / session / CI / PHP / programming expert.