Re: Rough text for State finding

On Sat, 2005-10-15 at 11:54 -0700, David Orchard wrote:
> I've written up rough text for the state finding primarily for the
> EPR-47 discussion.

Many thanks for getting this started.

>   If the direction is roughly correct, based on TAG and other
> feedback, I'll do the conversion to xmlspec, fill in the missing
> pieces, add refs, etc.  for more formal publication.
 
> 
> State and Applications
> 
>  
> 
> This is a draft TAG finding on State.  The purpose of the finding is
> to provide guidance to application developers on the use of Stateful
> or Stateless applications in a Web context.  It examines a variety of
> designs for a canonical example application to illustrate the complex
> trade-offs in the designs.  It uses HTML browser based and Web service
> based examples to show the similarities between the design decisions.
> The finding concludes with an analysis of the architectural property
> trade-offs between stateful and stateless applications.
> 
>  
> 
> What is State

I think this section comes to early. I'm not a fan of definitions
out of context in general, and it doesn't work for me in this
case in particular. I suspect it will work better to start with
the concrete story, accumulate 3 or 4 examples of state, and then
generalize with a definition.

> State is the data that pertains to an entity at a particular point in
> time.

At this point, with little context to worth with, questions
come to my mind like:
  is the diameter of the earth (a datum) pertinent to my homepage
  (an entity) or not?

Er... and is 'entity' a synonym for webarch:resource? If so, please
use resource instead (unless you're proposing that
we s/resource/entity/g, which is perhaps worth discussing).

>   A variety of software entities have state, ranging from applications
> to operating systems to network layers.  The state of an entity
> changes over time triggered by some kind of event. The event could be
> a network message, a timer expiring or an application message.
> Entities that do not have state, that is there is no trigger that
> causes a transition, are called stateless.  
> 
>  
> 
> Abstract example
> 
> Dirk decides to build an online banking application.  Customers will
> be able to view their account balances and make transfers.   The first
> step is logging on to the application.  When the customer selects
> accounts view, the banking application will ask them for their
> username and password.  If they have already entered their username
> and password, they will not be asked for it again.  The system will
> automatically log the customer out if they haven˙t done any activity
> for 10 minutes.  
> 
>  
> 
> We see a prototypical stateful application from the client
> perspective.  The application has 2 states: logged-in and
> not-logged-in.

Hmm... to my mind, there's lots more state to this app: the state of
my bank account is a bank balance, and probably a history of recent
transcations. But you're right to leave that out of this discussion,
as it's not really relevant to the open issues in web architecture.

A distinction that I think is perhaps more relevant is stateful
vs stateless protocols. In a stateless protocol, each message
carries all the relevant information with it; the server can
service each incoming message independently and need not remember
any state from one message to the next. In a stateful protocol,
processing message N might require the server to remember
something about messages previous to N.

Anyway, let's be good engineers and steal where we can. The
community consensus seems to be:

[[
A stateless server is one which treats each request as an independent
transaction, unrelated to any previous request. This simplifies the
server design because it does not need to allocate storage to deal with
conversations in progress or worry about freeing it if a client dies in
mid-transaction. A disadvantage is that it may be necessary to include
more information in each request and this extra information will need to
be interpreted by the server each time.

An example of a stateless server is a World-Wide Web server. These take
in requests (URLs) which completely specify the required document and do
not require any context or memory of previous requests.

Contrast this with a traditional FTP server which conducts an
interactive session with the user. A request to the server for a file
can assume that the user has been authenticated and that the current
directory and transfer mode have been set.
]]

http://foldoc.doc.ic.ac.uk/foldoc/foldoc.cgi?query=stateless&action=Search
http://en.wikipedia.org/wiki/Stateless_server


Clearly that bears refinement, since HTTP can be used in a stateful
manner too. But that's what we should start with.


> 
> 
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E

Received on Monday, 17 October 2005 20:08:32 UTC