i wonder if this message is because-of or inspite-of the observation that 4 of the 5 messages preceding it on the list are regarding sessions. that at least shows they're being used. would you take out the cookie functions too? i'm just coming back to webpy after a break and i was glad to see the session stuff fleshed out better. i'd like to understand how auth digest could be used -- in web.py or explained in your example as i dont follow how that would work--at least compared to the ease of using a session. thanks, -brentp
On Tue, Oct 21, 2008 at 6:39 AM, Aaron Swartz <[EMAIL PROTECTED]> wrote: > > Here's an excerpt from the book I'm working on about building > programmable web apps. It almost makes me want to take the sessions > module out of web.py. What do people think? Here it is: > > The second major choice [in designing the Web] was that the Web would > be "stateless". Imagine a network connection as your computer phoning > up HQ and starting a conversation. In a stateful protocol, these are > long conversations -- "Hello?" "Hello, welcome to Amazon. This is > Shirley." "Hi Shirley, how are you doing?" "Oh, fine, how are you?" > "Oh, great. Just great." "Glad to hear it. What can I do for you?" > "Well, I was wondering what you had in the Books department." "Hmm, > let me see. Well, it looks like we have over 15 million books. Could > you be a bit more specific?" "Well, do you have any by Dostoevsky?" > (etc.). But the Web is stateless -- each connection begins completely > anew, with no prior history. > > This has its upsides. For one thing, if you're in the middle of > looking for a book on Amazon but right as you're about to find it you > notice the clock and geebus! it's late, you're about to miss your > flight! So you slam your laptop shut and toss it in your bag and dash > to your gate and board the plane and eventually get to your hotel > entire _days_ later, there's nothing stopping you from reopening your > laptop in this completely different country and picking up your search > right where you left off. All the links will still work, after all. A > stateful conversation, on the other hand, would never survive a > day-long pause or a change of country. (Similarly, you can send a link > to your search to a friend across the globe and you both can use it > without a hitch.) > > It has benefits for servers too. Instead of having each client tie up > part of a particular server for as long as their conversation lasts, > stateless conversations get wrapped up very quickly and can be handled > by any old server, since they don't need to know any history. > > Some bad web apps try to avoid the Web's stateless nature. The most > common way is thru session cookies. Now cookies certainly have their > uses. Just like when you call your bank on the phone and they ask you > for your account number so they can pull up your file, cookies can > allow servers to build pages customized just for you. There's nothing > wrong with that. > > (Although you have to wonder whether users might not be better served > by the more secure Digest authentication features built into HTTP, but > since just about every application on the Web uses cookies at this > point, that's probably a lost cause. There's some hope for improvement > in HTML5 (the next version of HTML) since they're-- oh, wait, they're > not fixing this. Hmm, well, I'll try suggesting it.[^w]) > > [^w]: > http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-October/016742.html > > The real problem comes when you use cookies to create sessions. For > example, imagine if Amazon.com just had one URL: > http://www.amazon.com/ The first time you visited it'd give you the > front page and a session number (let's say 349382). Then, you'd send > call back and say "I'm session number 349382 and I want to look at > books" and it'd send you back the books page. Then you'd say call back > and say "I'm session number 349382 and I want to search for > Dostoevsky". And so on. > > Crazy as it sounds, a lot of sites work this way (and many more used > to). For many years, the worst offender was probably a toolkit called > WebObjects, which most famously runs Apple's Web store. But, after > years and years, it seems WebObjects might have been fixed. Still, new > frameworks like Arc and Seaside are springing up to take its place. > All do it for the same basic reason: they're software for building Web > apps that want to hide the Web from you. They want to make it so that > you just write some software normally and it magically becomes a web > app, without you having to do any of the work of thinking up URLs or > following REST. Well, you may get an application you can use through a > browser out of it, but you won't get a web app. > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web.py" group. To post to this group, send email to webpy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/webpy?hl=en -~----------~----~----~----~------~----~------~--~---
