No, no, and no.
Yes, yes and yes.
Sessions in all it's colours and flavors, are the only way to properly maintain state. Even with Ajax applications.
Earlier in this thread, I was hoping you would prove me wrong on that. What I think is going on here that you might be fading the line between sessions and php's session management system, those are not the same. Sessions (session layers) are used in many transfer protocols, HTTP not 'really' being one of them (as soon as the status changes to "200 OK" the connection is lost and the session ended). To maintain some sort of state in applications that are dependand of HTTP, session behaviour must be implemented some other way.
While php packs it's own build in session management system, in the form of a couple of session_* functions and a $_SESSION superglobal, this isn't the only way to employ sessions in php.
All one needs is way of identifying the client within a session, a storage method, and code to retrieve and set data using that method, for that perticular client.
Anything that performs that, is a session management system. I'm thinking up a custom session management system as I'm writing this.
With Ajax applications, one could
maintain state client-side, but that would require the client to tell the server exactly
what it wants, and can therefore never be used in an application that requires authentication. But even then the state would be lost upon page refresh.
Sessions are not objects (unless you use instantiations of a class called 'Session' of course).
You can properly identify a client within a database. You don't have to have people registered in your database to generate a random ID and tie it to a specific person.
I'm thinking you're not understanding what I am trying to say. I'm NOT saying you can't use a database to store data by client id, I'm NOT saying you need 'people' registered in a database, what I'm saying is you need to indentify the client by some characteristic, typicly string assigned by the server (id), I order to be able to retrieve the data specific for that client within this session.
You can NOT identify a client within a database. Assuming you mean identifiying a client by use of the data in the database, you can not get client specific
data from a database (or a flatfile it doesn't matter in this case), if you do not know what client to fetch for.
E.g. the client has to identify itself first.
That doesn't make any sense.
Well, it does. In order to start a session, the client has to have an identity. Currently, the only way that actually works that I know of (for HTTP dependant applications) are passing an id by the above mentioned methods.
Look, you can think what you want, but there are plenty of ways besides sessions to "maintain state". Some would argue that sessions aren't even secure, and I would tend to agree with them.
There are plenty of ways to employ sessions other than the standard, build-in session management system in php. There aren't any ways to maintain state other than using sessions.
True that session in HTTP dependant applications aren't that secure (you have to watch session hijacking and session fixation), but these are problems with the concept of sessions in the realm of all HTTP dependant solutions, not just php.
You need to stop thinking in absolutes and start realizing that there is a variety of ways to attack a problem and some may be better than what you currently use.
Actually I do that do a sickening extend. I tend to go so far that while I've a perfectly working solution I'll abandon it, just to try if something else might work better. Which isn't all bad, but makes creating an application a very time consuming process...
And one more thing... "sessions in all it's colors and flavors" doesn't make any sense either. Sessions are sesssions. It's an object. How can it have more than one color or flavor?!?!
I was refering to both session layers in other protocols (FTP, SMTP, FTPS, Telnet, more) and the variety of possible implementations of session management in HTTP dependant applications.
That is what I'm trying to say. Took me long enough to write, phewey...
I hope you see where I'm coming from now.