 Dear students, I have been explaining one thing and stressing one thing and repeating one thing again and again that the web is stateless and there has to be a mechanism of managing the state. And the persistence over here and in the slide you can see means that how to ensure and how to remember the state of the application, the state of the system, the state of the user and there are many techniques for doing this. So this module is kind of a little bit lengthy as compared to other modules because I will briefly go over those techniques to remember the state of the web, to remember the state of the application, to remember the state or what was happening. So what is state actually? Before we go into all of those details I will give you a brief background about it and the URL approach to remember the state and then another approach is the benefits of the URL approach and then the benefits of the other approaches. I will also talk about cookies and I will also talk about the how to manage the state of the client. Some of the words you may have heard but you may not be aware that what are the underlying concepts and what are the applications and what are the utilities and what are the profound impacts of all of those things. So let's go and deep dive into those interesting concepts. What is the state? The state of a database is based upon the variables. Now remember that a database is stateful. Web is stateless, stateful. So we store or we maintain the state of the database based upon the values in certain variables. Okay, those record those things and persistence is the capability of remembering those values and tracking those values. Right? So the objective over here is that if we remember the state and if we can track the state also then we don't have to establish connections again and again and we can remember things which will all boil down to the performance. Now remember that the client is a thin client. Thin client means that the client has limited processing power. The processing power is at the server. So we are going to be playing smart and intelligent to ensure that with a thin client we can get the most bang out of the buck as the quotation goes. And of course, HTTP is connectionless. Connectionless means that when the connection is established and the data transfer takes place, the text or the serial text transfer takes place, it closes and it doesn't remember even if the connection is again established from the same entities to the same destination. Right? And the server is also without the memory of the login server. So now this is a dilemma over here. The dilemma is that we would like the server to remember that we have logged in. Right? But it will close the connection. And to ensure the connection, we have to make it remember and it doesn't remember. So we have to play smart and use certain techniques and certain technologies to make it happen. So let's look at all of them. So for example, we have that registration page that is delivered. The username password is typed and is passed. Okay. And then it is a processed at the graphical user interface. Okay. And then the values are authenticated. And then what happens? This is what happens. State is stored in a randomly generated as ID session ID. Okay, the state is stored in a randomly generated ID. So the ID title so to say, or the identification is randomly generated. And that ID, the state of the system is stored. And this state ID is passed to the URLs. You may have seen that ID. Sometimes it has a name random ID. It's a random string attached to it. But that is the that that ID is being passed along the URLs to remember the state. Okay. Now what is the benefit? It is easy to use and maintain. It is obvious. It is easy to maintain but it's long and messy and insecure because I can read that ID over there. I can read what is there. I can change it and enter it and maybe adopt some but some other person's ID. And of course, when the user quits, this is gone. So it is not a good idea for the user to remember and to ensure the state ID. Let's move ahead. So we have this curious thing also. This is clean URL. It is easy to maintain and store and no limit on the size as compared to the session ID. Ask the session ID. However, user can still fake because I can open it in an editor. I can change it. I can submit it. Okay. Again, that the data is lost between the sessions. If the user quits unexpectedly or exits and it involves a user to save the state. This is not a good design approach. The user should not be involved in maintaining the state of the application because when the user quits or something happens, it is gone. So we talk about the cookies. What is a cookie? Cookie is a small piece of text. It's a text file. It is stored somewhere securely on your hard disk, of course, with your permission. And the browser can transparently access it as per the request of the server web server request. Your browser, the client accesses that cookie file, reads the contents. It is completely transparent. The user I only have to give the permission to read write the cookies location is not known. So it is apparently secure. It is apparently secure. And of course, as a programmer, I can set the expiration date of the cookie when the cookie will expire. But the size of the cookies limited is a few kilobytes, maybe even less. And if I change my machine, if I go from one machine to other machine, the cookie will be left on that machine. So my previous record with the cookies is lost. My prior activities, my prior settings, my prior password, they're gone. If I wanted them to be stored, and of course, can be tampered with, because any smart person who has certain amount of time can locate, can locate this cookie, edit that cookie, and make things happen as desired. So what do we do with this? This is simple, fast response, but can be secured. It is questionable, can be forged. Yes, of course. And there's no guarantee of the state. So we need reliable and robust mechanisms to ensure the storage of the state. And we need a thin client also. Why? Because that is desirable. That is to our advantage to have a wide usage base and better network efficiency. But the thing is that if we do it at the server level over here, it is more complex. And it is requires extensive coding at the programmer level. And remember that when the state is stored at the server level, that state has the corresponding information passes over the network. So we need to have better network efficiency to see that there is a trade off of the flexibility of the security of the performance at the server level at the client level. So as a web based database application designer, you have to weigh all those benefits and trade offs and then make the right decision. That's the purpose of this course. Thank you very much.