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

Re: [rest-discuss] Implementing MONITOR

Expand Messages
  • Walden Mathews
    Jan, ... I wonder what that means: meaningful to all resources . How would you describe the state transition (or transfer) that occurs in response to a
    Message 1 of 13 , Dec 28, 2003
      Jan,

      : > What are the arguments in favor of making MONITOR
      : > a generic method, I wonder?
      :
      : The one that convinced my has been made by Mark: MONITOR uniform
      : because it is meaningful to all resources, so it makes sense to have it.
      : Besides: I learn only by doing and MONITOR is great for this ;-)

      I wonder what that means: "meaningful to all resources". How would
      you describe the state transition (or transfer) that occurs in response
      to a MONITOR request? Maybe I don't understand.

      : In the risk of asking something I should actually now, what does
      : "incremental development" mean in the REST context?

      Nothing special for REST, just the idea of enhancing the
      system in functional increments. But as I think about it more,
      maybe me concern is really in the area of backward compatibility
      with already implemented resources.

      I really need an aswer to my question above, or I don't know
      what I'm talking about.

      Walden
    • Jan Algermissen
      ... 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
      Message 2 of 13 , Dec 28, 2003
        Walden Mathews wrote:
        >
        > Jan,
        >
        > : > What are the arguments in favor of making MONITOR
        > : > a generic method, I wonder?
        > :
        > : The one that convinced my has been made by Mark: MONITOR uniform
        > : because it is meaningful to all resources, so it makes sense to have it.
        > : Besides: I learn only by doing and MONITOR is great for this ;-)
        >
        > 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.

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


        Maybe I don't understand.

        Hmm...all I want is to experiment and contribute some code that is
        easy to deploy. So far I can see some very interesting consequences of
        a MONITOR method, among them the possibility to turn servers into feeds
        and direct them all to a single 'consumer'-resource that can do all kinds
        of interesting combinations.

        >
        > : In the risk of asking something I should actually now, what does
        > : "incremental development" mean in the REST context?
        >
        > Nothing special for REST, just the idea of enhancing the
        > system in functional increments. But as I think about it more,
        > maybe me concern is really in the area of backward compatibility
        > with already implemented resources.

        But isn't a simple 405 (501?) enough to tell a client that
        MONITOR isn't implemented? This works fine with PUT and DELETE
        and the other HTTP/1.1 methods.
        >
        > I really need an aswer to my question above, or I don't know
        > what I'm talking about.

        Jan
        >
        > Walden
        >
        > 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
      • 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 3 of 13 , Dec 28, 2003
          : > 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 4 of 13 , Dec 28, 2003
            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 5 of 13 , Dec 28, 2003
              > 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 6 of 13 , Dec 29, 2003
                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 7 of 13 , Dec 29, 2003
                  -----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 8 of 13 , Dec 29, 2003
                    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 9 of 13 , Jan 2, 2004
                      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.