Loading ...
Sorry, an error occurred while loading the content.

Re: [rest-discuss] client keeps its state

Expand Messages
  • Jan Algermissen
    ... We 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
    Message 1 of 33 , Apr 4, 2010
      On Apr 4, 2010, at 1:21 PM, Mike Kelly wrote:

      > This
      > 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.

      We 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).

      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

      Mail: algermissen@...
      Blog: http://www.nordsc.com/blog/
      Work: http://www.nordsc.com/
    • Andrew Wahbe
      ... 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.
      Message 33 of 33 , Apr 6, 2010
        On Tue, Apr 6, 2010 at 6:07 PM, Eric J. Bowman <eric@...> wrote:
        Andrew Wahbe wrote:
        > But from a REST perspective, you could think of them being part of a
        > single distributed client...

        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

        Anyways, it's just food for thought.

        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)

      Your message has been successfully submitted and would be delivered to recipients shortly.