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

Re: [rest-discuss] Implementing MONITOR

Expand Messages
  • Walden Mathews
    ... representation ... I m generally okay with that part. ... Depends on whether you re thinking or just tinking . This list is an architecture discussion
    Message 1 of 13 , Dec 28, 2003
    • 0 Attachment
      : > I wonder what that means: "meaningful to all resources".
      :
      : I'd say: since every resource 'has state' it makes sense to monitor its
      : state. MONITOR simply means: "POST a notification to the Reply-To URL
      : if the state changes". I think of this notification as being a
      representation
      : of the new state.

      I'm generally okay with that part.

      :
      : > How would
      : > you describe the state transition (or transfer) that occurs in response
      : > to a MONITOR request?
      :
      : This is beyond my REST-knowledge I think. Is it necessary that this is
      : doable? All I am sure of is that the response to MONITOR will be
      : a "201 Created" with a Location header identifying the monitor.

      Depends on whether you're "thinking" or just "tinking". This list is an
      architecture discussion list, so I would say yes, it is necessary.

      So I'll reiterate it: What resource state does MONITOR act on?

      Walden
    • Seth Johnson
      Is not the following the real issue here: The Reply-To URL would expect particular structures of representations of the monitored resource s state that the
      Message 2 of 13 , Dec 28, 2003
      • 0 Attachment
        Is not the following the real issue here:

        The Reply-To URL would expect particular structures of representations
        of the monitored resource's state that the monitored resource will
        POST to it. How do you make a MONITOR method that monitored resources
        would generically know how to handle, given this requirement?

        Much of REST is geared towards addressing the diversity of state
        structures that may arise.

        Seth Johnson


        -----Original Message-----
        From: Walden Mathews <waldenm@...>
        Date: Sun, 28 Dec 2003 17:37:50 -0500
        Subject: Re: [rest-discuss] Implementing MONITOR

        > : > I wonder what that means: "meaningful to all resources".
        > :
        > : I'd say: since every resource 'has state' it makes sense to monitor
        > : its state. MONITOR simply means: "POST a notification to the
        > : Reply-To URL if the state changes". I think of this notification
        > : as being a representation of the new state.
        >
        > I'm generally okay with that part.

        > : >
        > : > How would you describe the state transition (or transfer) that
        > : > occurs in response to a MONITOR request?
        > :
        > : This is beyond my REST-knowledge I think. Is it necessary that
        > : this is doable? All I am sure of is that the response to MONITOR
        > : will be a "201 Created" with a Location header identifying the
        > : monitor.
        >
        > Depends on whether you're "thinking" or just "tinking". This list is
        > an architecture discussion list, so I would say yes, it is necessary.
        >
        > So I'll reiterate it: What resource state does MONITOR act on?
      • Seth Johnson
        ... . . . or you d just say the monitored resource can send whatever representation it pleases (leaving aside content negotiation which might perhaps be part
        Message 3 of 13 , Dec 28, 2003
        • 0 Attachment
          > Is not the following the real issue here:
          >
          > The Reply-To URL would expect particular structures of
          > representations of the monitored resource's state that the monitored
          > resource will POST to it. How do you make a MONITOR method that
          > monitored resources would generically know how to handle, given this
          > requirement?
          >
          > Much of REST is geared towards addressing the diversity of state
          > structures that may arise.


          . . . or you'd just say the monitored resource can send whatever
          representation it pleases (leaving aside content negotiation which
          might perhaps be part of the original MONITOR request). But then why
          would it use POST to send the representation? (And how would it
          generically know what kind of POST structure is desired?)

          Seth Johnson
        • Jan Algermissen
          ... With an additional header that allows content negotiation to take place at the time of the MONITOR request. Propably Notify-Accept with the same
          Message 4 of 13 , Dec 29, 2003
          • 0 Attachment
            Seth Johnson wrote:
            >
            > Is not the following the real issue here:
            >
            > The Reply-To URL would expect particular structures of representations
            > of the monitored resource's state that the monitored resource will
            > POST to it. How do you make a MONITOR method that monitored resources
            > would generically know how to handle, given this requirement?

            With an additional header that allows content negotiation to take place
            at the time of the MONITOR request. Propably "Notify-Accept" with the
            same semantics as "Accept".

            Jan

            >
            > Much of REST is geared towards addressing the diversity of state
            > structures that may arise.
            >
            > Seth Johnson
            >
            > -----Original Message-----
            > From: Walden Mathews <waldenm@...>
            > Date: Sun, 28 Dec 2003 17:37:50 -0500
            > Subject: Re: [rest-discuss] Implementing MONITOR
            >
            > > : > I wonder what that means: "meaningful to all resources".
            > > :
            > > : I'd say: since every resource 'has state' it makes sense to monitor
            > > : its state. MONITOR simply means: "POST a notification to the
            > > : Reply-To URL if the state changes". I think of this notification
            > > : as being a representation of the new state.
            > >
            > > I'm generally okay with that part.
            >
            > > : >
            > > : > How would you describe the state transition (or transfer) that
            > > : > occurs in response to a MONITOR request?
            > > :
            > > : This is beyond my REST-knowledge I think. Is it necessary that
            > > : this is doable? All I am sure of is that the response to MONITOR
            > > : will be a "201 Created" with a Location header identifying the
            > > : monitor.
            > >
            > > Depends on whether you're "thinking" or just "tinking". This list is
            > > an architecture discussion list, so I would say yes, it is necessary.
            > >
            > > So I'll reiterate it: What resource state does MONITOR act on?
            >
            > To unsubscribe from this group, send an email to:
            > rest-discuss-unsubscribe@yahoogroups.com
            >
            >
            >
            >
            > Yahoo! Groups Links
            >
            > To visit your group on the web, go to:
            > http://groups.yahoo.com/group/rest-discuss/
            >
            > To unsubscribe from this group, send an email to:
            > rest-discuss-unsubscribe@yahoogroups.com
            >
            > Your use of Yahoo! Groups is subject to:
            > http://docs.yahoo.com/info/terms/

            --
            Jan Algermissen http://www.topicmapping.com
            Consultant & Programmer http://www.gooseworks.org
          • Seth Johnson
            ... From: Jan Algermissen Date: Mon, 29 Dec 2003 10:30:55 +0100 Subject: Re: [rest-discuss] Implementing MONITOR ... So the
            Message 5 of 13 , Dec 29, 2003
            • 0 Attachment
              -----Original Message-----
              From: Jan Algermissen <jalgermissen@...>
              Date: Mon, 29 Dec 2003 10:30:55 +0100
              Subject: Re: [rest-discuss] Implementing MONITOR

              > Seth Johnson wrote:
              > >
              > > Is not the following the real issue here:
              > >
              > > The Reply-To URL would expect particular structures of
              > > representations of the monitored resource's state that the
              > > monitored resource will POST to it. How do you make a MONITOR
              > > method that monitored resources would generically know how to
              > > handle, given this requirement?
              >
              > With an additional header that allows content negotiation to take
              > place at the time of the MONITOR request. Propably "Notify-Accept"
              > with the same semantics as "Accept".


              So the monitored resource would have to only POST existing
              standard "content types?"

              Seth Johnson
            • Jan Algermissen
              ... Hmm...yes. what is the problem with this? Or in other words: why is this a problem in the case of MONITOR but not a problem for the other methods? Or am I
              Message 6 of 13 , Dec 29, 2003
              • 0 Attachment
                Seth Johnson wrote:
                >
                > -----Original Message-----
                > From: Jan Algermissen <jalgermissen@...>
                > Date: Mon, 29 Dec 2003 10:30:55 +0100
                > Subject: Re: [rest-discuss] Implementing MONITOR
                >
                > > Seth Johnson wrote:
                > > >
                > > > Is not the following the real issue here:
                > > >
                > > > The Reply-To URL would expect particular structures of
                > > > representations of the monitored resource's state that the
                > > > monitored resource will POST to it. How do you make a MONITOR
                > > > method that monitored resources would generically know how to
                > > > handle, given this requirement?
                > >
                > > With an additional header that allows content negotiation to take
                > > place at the time of the MONITOR request. Propably "Notify-Accept"
                > > with the same semantics as "Accept".
                >
                > So the monitored resource would have to only POST existing
                > standard "content types?"

                Hmm...yes. what is the problem with this? Or in other words: why
                is this a problem in the case of MONITOR but not a problem for
                the other methods?

                Or am I misunderstanding your point?

                Jan

                >
                > Seth Johnson

                --
                Jan Algermissen http://www.topicmapping.com
                Consultant & Programmer http://www.gooseworks.org
              • Seth Johnson
                ... Well, I think that POST is supposed to be much more flexible than that. But I m not sure it matters, after all. Seth Johnso -- DRM is Theft! We are the
                Message 7 of 13 , Jan 2, 2004
                • 0 Attachment
                  Jan Algermissen wrote:
                  >
                  > Seth Johnson wrote:
                  > >
                  > > -----Original Message-----
                  > > From: Jan Algermissen <jalgermissen@...>
                  > > Date: Mon, 29 Dec 2003 10:30:55 +0100
                  > > Subject: Re: [rest-discuss] Implementing MONITOR
                  > >
                  > > So the monitored resource would have to only POST existing
                  > > standard "content types?"
                  >
                  > Hmm...yes. what is the problem with this? Or in other words: why
                  > is this a problem in the case of MONITOR but not a problem for
                  > the other methods?
                  >
                  > Or am I misunderstanding your point?


                  Well, I think that POST is supposed to be much more flexible than that. But
                  I'm not sure it matters, after all.

                  Seth Johnso


                  --

                  DRM is Theft! We are the Stakeholders!

                  New Yorkers for Fair Use
                  http://www.nyfairuse.org

                  [CC] Counter-copyright: http://realmeasures.dyndns.org/cc

                  I reserve no rights restricting copying, modification or distribution of
                  this incidentally recorded communication. Original authorship should be
                  attributed reasonably, but only so far as such an expectation might hold for
                  usual practice in ordinary social discourse to which one holds no claim of
                  exclusive rights.
                Your message has been successfully submitted and would be delivered to recipients shortly.