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

Re: [rest-discuss] Implementing MONITOR

Expand Messages
  • Jan Algermissen
    ... Yes... (see Mark s reply) ... The one that convinced my has been made by Mark: MONITOR uniform because it is meaningful to all resources, so it makes sense
    Message 1 of 13 , Dec 28, 2003
    • 0 Attachment
      Walden Mathews wrote:
      >
      > Hi Jan,
      >
      > I read quickly...
      >
      > I don't like MONITOR as a "generic" method.
      >
      > Monitoring is a stateful activity (can't think of a better
      > wording for that, unfortunately). Ergo, Monitors are
      > resources proper.

      Yes... (see Mark's reply)

      >
      > That may be overkill in a lot of cases, but your question
      > seems to bring this out.
      >
      > 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 ;-)

      ( http://lists.w3.org/Archives/Public/www-ws-arch/2003Jan/0253.html )

      It seems that incremental
      > development is a counter-argument...

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

      Thanks.

      Jan
      >
      > Walden
      >
      > ----- Original Message -----
      > From: "Jan Algermissen" <jalgermissen@...>
      > To: "rest-discuss" <rest-discuss@yahoogroups.com>
      > Sent: Saturday, December 27, 2003 6:03 PM
      > Subject: [rest-discuss] Implementing MONITOR
      >
      > : Hi--
      > :
      > : as promissed, I am right in the middle of implementing MONITOR
      > : (using Apache/mod_perl) and, naturally, questions pop up immediately.
      > :
      > : Here is my approach:
      > :
      > : A server that has the MONITOR module loaded accepts requests of the form:
      > :
      > : MONITOR /index.html HTTP/1.1
      > : Host: example.org
      > : Reply-To: http://www.some.org/my-feeds
      > :
      > : The server will send notifications to the Reply-To URI everytime
      > : the resource's state changes. mailto: URIs are allowed as values
      > : for the Reply-To header.
      > :
      > : The question I face is how to tell the server to stop sending
      > : notifications...
      > :
      > : - in the case of mailto: URIs
      > :
      > : * I really want to avoid the receiver sending email replies to the
      > server
      > : to continue the monitoring, as suggeted in
      > :
      > : http://internet.conveyor.com/RESTwiki/moin.cgi/HttpEvents
      > :
      > : - in the case of http: URIs
      > :
      > : * what about returning a FORBIDDEN response code by the receiver?
      > :
      > :
      > : Or would it be a solution to send a MONITOR again, this time providing
      > : an additional header that will stop the 'subscription'? That way it would
      > : be possible to also specify time intervals during which notifications
      > : are desired, e.g.:
      > :
      > :
      > : MONITOR /index.html HTTP/1.1
      > : Host: example.org
      > : Reply-To: http://www.some.org/my-feeds
      > : Notify-Stop: Sat, 27 Dec 2003 22:31:22 GMT
      > :
      > : or
      > :
      > : MONITOR /index.html HTTP/1.1
      > : Host: example.org
      > : Reply-To: http://www.some.org/my-feeds
      > : Notify-Pause-Until: Sat, 27 Dec 2003 22:31:22 GMT
      > :
      > : or
      > :
      > : MONITOR /index.html HTTP/1.1
      > : Host: example.org
      > : Reply-To: http://www.some.org/my-feeds
      > : Notify-Schedule: <more complex time information>
      > :
      > :
      > : Would this be RESTful?
      > :
      > :
      > : Jan
      > :
      > :
      > :
      > :
      > : --
      > : Jan Algermissen http://www.topicmapping.com
      > : Consultant & Programmer http://www.gooseworks.org
      > :
      > : 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/
      > :
      > :
      > :
      > : __________ NOD32 1.586 (20031226) Information __________
      > :
      > : This message was checked by NOD32 Antivirus System.
      > : http://www.nod32.com
      > :
      > :

      --
      Jan Algermissen http://www.topicmapping.com
      Consultant & Programmer http://www.gooseworks.org
    • 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 2 of 13 , Dec 28, 2003
      • 0 Attachment
        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 3 of 13 , Dec 28, 2003
        • 0 Attachment
          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 4 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 5 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 6 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 7 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 8 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 9 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 10 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.