Re: Draft State Finding

Dave - just some stream-of-consciousness thoughts as I go through it. 
My apologies for not responding to your first draft ...

Section 1

- re "on the use of Stateful or Stateless applications in a Web
context", I think "on the use of state in Web based application
development" would be more accurate, since it's more than just
stateful/stateless *applications* that are being considered

- the last sentence can be similarly tweaked

- I'm uncomfortable with Web services examples being here when the
title of the draft is "State in Web application design".  The obvious
fix is to change the title, but I think you know that wouldn't be my
preference 8-)

Section 2

- "The state of an entity changes over time triggered by some kind of
event" - this initially struck me as incorrect, but I realize you
might mean even internal, encapsulated events; for example, a clock
changes state not (usually) by any external stimulus.  I'd suggest
making this explicit, and in fact, I think a clock makes for a good
example.

- I don't understand what "application state" is by that definition. 
You say that it's resource state, but in my experience, application
state is most commonly (though I admit this depends what communities
you associate with) defined to be equivalent to session state. 
Perhaps some simple examples would help with those definitions too. 
Also, you might want to turn this into a standalone glossary; some
(most?) of the problems I talk about here could probably be alleviated
with one, I think

- the definition of session state doesn't actually define it, it just
describes an affect it can have.  But I expect the resolution of the
aforementioned application/session state issue will motivate a new
definition ...

FWIW, this is how I see the definitions;

- application state; either information that identifies a state in the
application's state machine, or a name for the state itself.  Also, in
a Web context, the "application" is the Web application; I got the
impression (correct me if I'm wrong) that you may have used it in the
draft at least once, to refer to the browser itself.
- session state; a synonym for application state
- resource state; the "data" used by an application.  For example, the
invoice and billing data in an accounting system.

- I have some issues with the last paragraph, but I'll address them
indirectly in latter sections ...

Section 3.1

- I'm not aware of anybody having described a browser as stateless. 
What's typically referred to as "stateless" in a Web context is the
interaction such that the browser is required to manage
application/session state.  Also typical, is that when a component
(client or server) is described as being "stateless", it refers to
session/application state only, not resource state.  So "stateless
server" means that the client stores session state, ala REST. 
Similarly, "stateless client" means the server stores session state,
such as in remote desktop systems like VNC.  FWIW, I think your draft
would do well if all it did was document this terminology! 8-)

- re "For example, web browsers are not storing multiple megabytes of
data (like a digitized signature) per URI", but you then go on to say
that it stores cached pages, and that can easily reach multi-megabyte
ranges (Firefox's default is 50MB).

- regarding the explicit calling out of Firefox, AIUI Safari saves
window info too, so perhaps you could just say "there are browsers
which ..."

- re "In addition to state that the application directly understands
and manages", by "application" do you mean browser?  If so, I'd
suggest avoiding that term because it conflicts with the other use of
application, i.e. the Web application.

- that whole last paragraph could probably be better tied in to the
document.  For example, it talks about cookies but not in terms of
session state.  Or perhaps there's some disconnect here with respect
to the definitions as I mentioned above.  Dunno.

Section 3.2

- re "Probably the primary entity that manages state is a server".  I
think you mean resource state there, but can't tell.

- re the FOLDOC definition of "stateless server", again, it's
referring only to session state which should be called out IMO.

- "Many of the Web applications that are built on top of a Web server
are very stateful".  I'd suggest that it would be clearer to rephrase
that as "Many interactions on the Web today are stateful".

- In the last sentence of the first paragraph, I don't know what a
"stateful application" is.  Is that resource state?

- "Many Web and Web service applications deployed today use stateful
servers because a stateful server achieves desirable characteristics
in the system".  I think I'd need to see some evidence for that.  In
my experience, most stateful Web apps are that way because deployed
infrastructure requires it, e.g. cookie auth to avoid the ugly dialog
box, or shopping carts on the server because HTML doesn't support
drag-and-drop.  I do agree that statefulness has its place in some
apps, but I think "many" might oversell the situation.  And I don't
buy the banking example.  Sure, performance is often gained (higher
throughput due to reduced message size), but reliability, scalability,
and availability are, in my experience, generally reduced as a result
of the use of stateful interactions.

Section 4

- 2nd sentence, 2nd paragraph, you swap into first person mode ("I
believe").  Looks like you've got some concensus gathering to do. 8-)

Section 4.2

- I don't quite follow what you're talking about in paragraph 3, but
from a cookie security perspective, it doesn't seem like you're
covering what I consider the most important concern; that when a
message's semantics become a function of information not found within
the message (as is commonly the case with cookies, though not always
as you point out in 8.3), then this introduces a new vector for MITM
attacks.

Section 4.3

- this is pretty information-rich.  Can it be put in example form
perhaps?  I'm not sure that a Web developer would get much from it in
its current state.  Maybe it's just me though.

Section 4.4

- re "The system, whether it is the client or the server or the
network, must contain the state" seems to be missing the point that if
the session state is split between client and server, that partial
failures become more of a problem.

- I'd like to re-read this again once the terminology issues are addressed.

Section 5 & 6

- will need to revisit later too

Section 7

- re the title, "Stateful Resource Identification", I'd suggest
removing "Stateful" since it goes without saying that resources have
state.

Section 7.2

- suggest changing the title to "Gateway URIs" (or "URI per
gateway"?), as well as the references to "dispatch URIs".  I think
that name better describes the architecture.

Section 8.2

- you almost mention the caching cost, but not quite.  suggest calling
it out explicitly in the last paragraph.

Section 9.2

- I think the defense of "protocol independence" is out of place in this draft

Sections 9.3-9.6

- see comment above about Web services

Cheers,

Mark.

Received on Saturday, 22 April 2006 21:20:28 UTC