[eluser]glopglop[/eluser]
[quote author="WanWizard" date="1285034135"]1) all session solutions use a cookie. The only alternative is PHP's native sessions that supports adding the session ID to the URL, which is something you shouldn't do.
2) you should always store data server side. That rules out the cookie-only solution CI provides by default, and leaves only the database solution.
3) 3rd party solutions are available that use different storage solutions, file based (native session) or mixed.
I've still have to run into the first situation where file based session storage is a better solution than database storage. The only situation I can think of is if you have a server with a fast disk and a slow database (shared hosting?). But imho that doesn't solve any thing, because it will give you slighly faster session I/O, but your application itself will still be very slow, since session I/O is limited to one read and one write per session (you have to extend the session class for that), the rest of your application requires a lot more database access, and with probably a lot more complex queries...[/quote]
As I do plan to use Amazon Database services for DB hosting, inserting elements in the DB for session is going to cost a lot of money (as new element insertion is part of the pricing).
I was much more considering using HTTPS & encrypted session ID in the URL (as on client-side I am not using a web browser but an Iphone application accessing XML RPC services powered by CI)
