Re: the meaning of stateless

Thanks, everyone. This has been very informative.

b.c.


On Thu, Apr 25, 2013 at 12:53 PM, Jan Algermissen <
[email protected]> wrote:

>
> On 25.04.2013, at 21:47, "Robert Brewer" <[email protected]> wrote:
>
> > Hi Brian,
> >
> > Markus came closest when he distinguished "application state" from
> "resource state". But even that doesn't quite go far enough until you
> define what an "application" is and understand what "state" is.
> >
> > Lots of web developers think an "application" is "the code I wrote in
> Python or Ruby that runs on the server." But that is worlds apart from the
> way Roy uses it. He uses it in its original sense of "accomplishing a goal
> with something". Building a house is an application of (among other things)
> boards, nails, and a hammer.
> >
> > Lots of web developers think that "state" means "data in my database".
> But that is worlds apart from the way Roy uses it. He uses it in its
> original sense of "the current node in a state machine." Let's say you
> supply boards and nails. If my application is "building a house", the
> "state" of my application is not how many boards and nails you have. It is
> not even how many boards and nails I have. It is how much of my house has
> been built. The state is advanced by building walls and assembling them
> together. Those have sub-states, some of which involve buying more boards
> and nails.
> >
> > The interaction between me and you is "stateless" if I can buy boards
> and nails from you without you knowing anything about how much of my house
> has been built, or even if my application of what you provide is "building
> a house". If I have to talk to the same sales rep every time then it's not
> stateless. If I've bought 100 board feet and you pre-order another 900
> board feet from your vendor because I'm building a house then it's not
> stateless. If you keep 1000 board feet on hand because building a house is
> a very common operation, then it might be stateless, because your business
> doesn't know anything about my application.
> >
> > Now let's say you not only provide boards and nails, but also hammers,
> and plans, and labor, and installation. In fact, the house is built by you
> on your property. But I get to pick out the floorplan and curtain colors.
> The application has not changed. The state machine has not changed. The
> methods used to advance the application from one state to the next have not
> changed. What has changed?
> >
> > 1) Who does which activity to advance the state machine. Most of it used
> to be me. Now most of it is you.
> > 2) Where the current node of the state machine is kept; that is, how
> much of my house has been built. That information used to be kept on my
> property. Now it is kept on your property.
> >
> > The interaction between me and you can no longer be "stateless" because
> you know how much of my house has been built. If I ask you to change the
> floorplan or the curtain colors, first you have to authenticate me, and
> then you have to go to the property to inspect the state to see if you can
> comply with the request. That's two scalability problems you didn't have
> before. It doesn't mean you're not raking in the dough. But I'm no longer
> advancing the application state except at two points; in many cases, I'm
> not even doing that--I'm configuring the application state machine instead.
>
> Wow! What a great explanation of 'Application'.
>
> +1
>
> Jan
>
> >
> >
> > Robert Brewer
> > [email protected]
> > 
>
>