Hi Mark,
Thank you very much for the feedback. It is most appreciated!
> I think a point of confusion remains in this article. I agree that
> Roy's terminology in his dissertation is a little bit confusing, but
> where he refers to "client-stateless-server" (that you reference),
> the "stateless" part there isn't an adjective for the noun "server",
> it refers to the connector. It's true that stateless servers, by
> definition, can only participate in stateless exchanges, but the
> converse isn't true
This is a most interesting distinction that I had not taken into account
thus far. There are three components in a networked application that may
or may not have some notion of state: client, service and connector
(communication mechanism).
HTTP is a stateless connector. But doesn't HTTP 1.1 include persistent
connections? This must introduce some idea of state.
FTP is an example of a stateful connector since it defines messages
specifically to open and close connections.
> a server with state can still participate in
> stateless message exchanges. It just can't have *session* state, aka
> state which can be referenced by messages for the purpose of
> affecting the semantics of those messages.
This still confuses me. What about web applications where the HTTP message
has a header containing a session ID; isn't this an example of a stateful
server whose messages reference state?
Or is it the case that when you say "can't have *session* state" you are
referring to "session state" as being messages whose type changes (as in
FTP) as opposed to changing content (as in HTTP).
> Regarding "stateless clients", I don't think that's what you mean to
> be discussing. AFAIK, the only "stateless client" architectural styles
> are "remote session" styles like telnet or VNC where session state is
> *entirely* on the server. What you appear to be describing in those
> two sections are styles where the state of any session is split between
> client and server.
Good point. I shall correct this.
> I disagree with your summation of the tradeoffs of stateless vs.
> stateful when you say "a stateful server [...] is more amenable to
> message sequences i.e. application level protocols.".
Can you elaborate further on this?
In that section of the article I meant to refer to this message in the
"Stateful Web Services" thread:
http://lists.w3.org/Archives/Public/www-ws/2004Nov/0018.html
(I have just corrected the link).
In the "PRO STATEFUL" list I found:
- Requests can have sequence numbers, so that the server can detect
duplicate and out-of-order requests. Thus requests need not be
idempotent, and multiple-request interaction patterns can be validated
Regards,
Rob
:)
--
Robert Mark Bram
http://phd.netcomp.monash.edu.au/RobertMarkBram/default.asp
B.Comp.(Systems Development/Business Systems)
B.Net.Comp.(Hons)
Doctor of Philosophy Student
School of Network Computing
Faculty of Information Technology
Monash University
Peninsula Campus
McMahons Rd
Frankston, VIC 3199
AUSTRALIA