Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: "omniscient debugging" for Perl

by praveenray (Novice)
on Jul 05, 2005 at 16:12 UTC ( [id://472501]=note: print w/replies, xml ) Need Help??


in reply to "omniscient debugging" for Perl

If I remember it right, according to Autrijus's presentation at YAPC::Toronto, we'll be able to do exactly this in Perl 6. He was even talking about being able to maintain entire state of the application in few KiloBytes..thereby eliminating the need for cookies !! Really cool. Whenever we're blessed with it.

Replies are listed 'Best First'.
Re^2: "omniscient debugging" for Perl
by mpeters (Chaplain) on Jul 05, 2005 at 16:20 UTC
    How does this eliminate the need for cookies (I'm assuming you mean web browser cookies)? No matter how much you can save on the server side, HTTP is stateless and you need some piece of data coming from the client to indicate that this request is tied to a previous request (or series of requests). Even if you could save the application state of every Apache child (assuming Apache) for every simultaneous user, there is still no way to figure out which one to use for the next request.

    -- More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk. -- Bruce Schneier
      How does this eliminate the need for cookies? ... No matter how much you can save on the server side, HTTP is stateless and you need some piece of data coming from the client to indicate that this request is tied to a previous request ...
      If you can represent the entire state compactly enough, you can send it back to the client with every response and receive it from the client with every request. Now you don't need to store any state on the server, nor do you need cookies on the clients.

      For example, take a look at Web Authoring System Haskell. It records a journal of client-server interactions, sends this journal to the client as part of every response (in a hidden field in an HTML form), and when the form is submitted, it replays the journal on the server to recreate the state.

      Cheers,
      Tom

        Whether you send the data to the client as a hidden field in a form, or as a cookie it's basically the same thing. And by using a cookie you can be sure that the data will be in every request the user sends (GET's, links, images, media, etc) from then on, not just the results of a form.

        While this would reduce the need for server side storage of sessions, this can already be done. There are lots of people who instead of sending a session id in the cookie (or hidden field) will send a serialized version of an object or hash which they can then unserialize at the next request.

        -- More people are killed every year by pigs than by sharks, which shows you how good we are at evaluating risk. -- Bruce Schneier

        This sounds horribly insecure to me. How do you stop the client from changing the state into one it shouldn't.

        I think I'll keep cookies with a randomly-generated ID crossreferenced to a database.

        "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://472501]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (1)
As of 2024-05-25 14:06 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found