Re: Draft State Finding

David Orchard wrote:
> Per my action item and for our discussions, I attach a rough draft of a
> finding on state.
>  
> This probably should get a URI, etc.

It already has two:
  http://lists.w3.org/Archives/Public/www-tag/2006Feb/att-0076/State.html
  http://lists.w3.org/Archives/Public/www-tag/2006Feb/att-0076/state.xml
:)

Nice.  I like the approach.  Especially the last para in section 2.

...

I see an editorial nit:
[[
It is important for our analysis to state that a client that stores data related
to an application, such as username/passwords for URIs, is considered a stateful
application
]]

The dual use here of "state" reads a little awkwardly.  Maybe "It is important
for our analysis to affirm that ..."?

...

In section 4, how would you characterize the sometimes-used technique of
encoding state in a URI returned by the server?

...

Section 6:  What is an EPR?  The term seems to be introduced without
explanation.  I'm guessing, from context, an "End Point Reference".

More generally, I think how EPRs in section 6 relate to state needs to be
established more clearly.

...

Section 7:  I think that one factor to be mentioned might be working with (as
opposed to against) web architecture.   Or do you regard that as subsumed by the
factors you do mention?  My presumption is that, as an architectural finding,
the goal is to explain why and how various techniques work well or not so well
in a Web context.

...

Section 7.1:  the actual text doesn't obviously reflect the section title.  Or
only a very particular aspect of "Ease of Application construction".

...

Section 7.2:  I think you are alluding to, but don't explicitly say, that
security requirements may be an important determinant of where state is to be
stored.  (E.g. state with sensitive content probably needs to be kept on a
secure server, etc...)

I think the techniques that you mention would flow logically from this.

...

Section 7.3:  I feel this topic should probably be more prominent.  Maybe the
first in section 7?  My understanding is that scalability is a key reason for
the success of HTTP's essentially stateless approach.  Approaches that place
state on an application server potentially restrict the application's scope for
scalability, etc., etc.

...

Section 7.4: typo "Anecdatally,"

...

Finally,  I feel there may be more to say about the role of intermediaries, such
as portals.  I'm currently working related to portal developments, and find that
I'm very unhappy about the way that these seem to be going.  There seems to be
some reinvention of the web going on here, and the driver for this seems to be,
in part, accessibility to relevant state information (initially:  session,
authentication, but more seems to be creeping in).

...

#g

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Wednesday, 22 February 2006 11:02:59 UTC