Re: [rest-discuss] client keeps its state
- On Apr 4, 2010, at 1:21 PM, Mike Kelly wrote:
> ThisWe need not put any semantic 'magic' in the notion of steady state: When the application state of some Web application consists of parts that have different volatility or otherwise make no sense to stuff into a entity the processing rules of the media type of the primary representation can provide rules for downloading the various parts (think along the lines of HTML and images, style sheets, etc).
> is where, for me, the parallel between the human web and the machine web
> begins to break down a bit and the comparison stops making sense - and
> so it's also where the meaning and value of a 'steady state' becomes a
> bit confused.
These processing rules are independent of the application in question, they are defined in the context of the media type of the primary representation only. For example, HTML's processing rules apply regardless of what Web application a browsers interacts with.
User agents can provide configuration options that allow controlling the actual behavior regarding the processing rules. For example, most browsers allow us to turn off the automatic image downloading.
One the user agent's component for handling the given media type is done with applying the processing rules it reaches a steady state and hands control to the next layer.
The differentiation between human and machine client really only applies *after* the steady state has been reached. Before that it is all automatic, media type specific processing rules.
Jan Algermissen, Consultant
NORD Software Consulting
- On Tue, Apr 6, 2010 at 6:07 PM, Eric J. Bowman <eric@...> wrote:Andrew Wahbe wrote:> single distributed client...
> But from a REST perspective, you could think of them being part of a
Not sure what you mean. In REST, "client" specifically means "client
connector", so do you mean a single distributed client connector, or a
single distributed user agent? Or is it a single distributed user,
driving numerous user agents (like Google driving googlebot)?
Yes I see how that's confusing. By "client" I mean the "thing running the application" -- perhaps "distributed user-agent" is the right terminology here. Consider an application that consists of multiple hypermedia formats, could be VoiceXML + CCXML or Atom + HTML. It could be the case that the markup is processed by a single process or it could be that different processes are handling the individual markup languages and coordinating somehow. The server is just seeing the HTTP requests and shouldn't really care how the user agent is internally constructed. Of course as I mentioned cookies break this -- it's another way that they are not ideal. VoiceXML/CCXML systems can sometimes be broken into as many as 3 separate components all making requests related to a single application session: the CCXML processor, the VoiceXML processor and a speech processor (performing speech recognition and fetching grammar files). Some of the related protocols have mechanisms to try and coordinate cookies: e.g. http://tools.ietf.org/html/draft-ietf-speechsc-mrcpv2-20#section-6.2.15
Actually, at second glance, CCXML seems more akin to Xforms -- is it an
MVC application the server transfers to the user agent? MVC on the
user agent is a powerful REST design pattern that can be adapted to
That's maybe one way to think about it. It is a finite state machine that communicates via messages/events to resources in an underlying client platform. Events cause state transitions, transitions handlers can send messages back to the platform or place HTTP requests to transition to a new page (or do various other things). I see parallels between this model and an Ajax application -- which can be thought of as a state machine: each "view" is a different state often labelled with a URI fragment (e.g. #inbox in Gmail)