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

How a CLI could use the client environment executables files?

Expand Messages
  • Philippe Rathé
    Hello all, I would like to code my own atompub client and server. I use atompub to expose different hierarchical collections of members.I would like the client
    Message 1 of 8 , Jun 1, 2012
    • 0 Attachment
      Hello all,

      I would like to code my own atompub client and server. I use atompub
      to expose different hierarchical collections of members.I would like
      the client being an interactive command line tool. Additionally to be
      used as a feed reader, a consumer of the CLI would probably use it
      for: bookmarking a collection; refreshing bookmarked collections;
      using diff tools to compare local files and then POSTing the output
      content to a collection; etc.

      The biggest challenge I face is how the CLI could use the client
      environment executables files restfully?

      I need to access the diff tools on the client-side system. Does it
      fail any constraints the fact that the CLI would try to access the
      diff executable tools under the hood? I would provide to the consumer
      the hypermedia controls necessary to fill in the arguments that will
      be passed to the executables. Just like HTML forms. What about
      code-on-demand instead? The client would executes, as an example,
      shell scripting fragment depending on the client environment setup
      capabilities. Just like the browser executes JavaScript? It has some
      advantages that the client could be partly able to update itself.

      Otherwise I would need to let the server do the diff which will be
      retrieve by the client. But the client and the server will most of the
      time be on the same machine or local network. The client needs to
      access the file system and do operations on files, which the local web
      server could do.

      Any advices? Thanks.
      -- Philippe
    • mike amundsen
      Philippe: sounds like an interesting project. first, the REST style focuses primarily on the network-level software details; the implementation within the
      Message 2 of 8 , Jun 1, 2012
      • 0 Attachment
        Philippe:

        sounds like an interesting project.

        first, the REST style focuses primarily on the network-level software details; the implementation within the servers and clients is left open for your own choices. 

        However, Chapter 1 of Fielding's dissertation does a good job of describing the primary software model he had in mind esp. section 1.2[1]. I think you'll find some guidance there and see that your idea of using internal components on the client (i.e. diff, etc.) is well within the scope of an implementation w/ REST characteristics.

        Hope this helps.


        mca
        http://amundsen.com/blog/
        http://twitter.com@mamund
        http://mamund.com/foaf.rdf#me




        On Fri, Jun 1, 2012 at 7:12 PM, Philippe Rathé <prathe@...> wrote:
        Hello all,

        I would like to code my own atompub client and server. I use atompub
        to expose different hierarchical collections of members.I would like
        the client being an interactive command line tool. Additionally to be
        used as a feed reader, a consumer of the CLI would probably use it
        for: bookmarking a collection; refreshing bookmarked collections;
        using diff tools to compare local files and then POSTing the output
        content to a collection; etc.

        The biggest challenge I face is how the CLI could use the client
        environment executables files restfully?

        I need to access the diff tools on the client-side system. Does it
        fail any constraints the fact that the CLI would try to access the
        diff executable tools under the hood? I would provide to the consumer
        the hypermedia controls necessary to fill in the arguments that will
        be passed to the executables. Just like HTML forms. What about
        code-on-demand instead? The client would executes, as an example,
        shell scripting fragment depending on the client environment setup
        capabilities. Just like the browser executes JavaScript? It has some
        advantages that the client could be partly able to update itself.

        Otherwise I would need to let the server do the diff which will be
        retrieve by the client. But the client and the server will most of the
        time be on the same machine or local network. The client needs to
        access the file system and do operations on files, which the local web
        server could do.

        Any advices? Thanks.
        -- Philippe


        ------------------------------------

        Yahoo! Groups Links

        <*> To visit your group on the web, go to:
           http://groups.yahoo.com/group/rest-discuss/

        <*> Your email settings:
           Individual Email | Traditional

        <*> To change settings online go to:
           http://groups.yahoo.com/group/rest-discuss/join
           (Yahoo! ID required)

        <*> To change settings via email:
           rest-discuss-digest@yahoogroups.com
           rest-discuss-fullfeatured@yahoogroups.com

        <*> 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/


      • Philippe Rathé
        Thanks Mike, you are right, I have to make decisions in what concerns the architecture of my client but that is not REST related. But I don t know at which
        Message 3 of 8 , Jun 2, 2012
        • 0 Attachment
          Thanks Mike,

          you are right, I have to make decisions in what concerns the
          architecture of my client but that is not REST related. But I don't
          know at which level it is important or not that the consumer of the
          user agent knows about those details.

          On Fri, Jun 1, 2012 at 10:14 PM, mike amundsen <mamund@...> wrote:
          > Philippe:
          >
          > sounds like an interesting project.
          >
          > first, the REST style focuses primarily on the network-level software
          > details; the implementation within the servers and clients is left open for
          > your own choices.
          >
          > However, Chapter 1 of Fielding's dissertation does a good job of describing
          > the primary software model he had in mind esp. section 1.2[1]. I think
          > you'll find some guidance there and see that your idea of using internal
          > components on the client (i.e. diff, etc.) is well within the scope of an
          > implementation w/ REST characteristics.
          >
          > Hope this helps.
          >
          > [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm#sec_1_2
          >
          > mca
          > http://amundsen.com/blog/
          > http://twitter.com@mamund
          > http://mamund.com/foaf.rdf#me
          >
          >
          >
          >
          > On Fri, Jun 1, 2012 at 7:12 PM, Philippe Rathé <prathe@...> wrote:
          >>
          >> Hello all,
          >>
          >> I would like to code my own atompub client and server. I use atompub
          >> to expose different hierarchical collections of members.I would like
          >> the client being an interactive command line tool. Additionally to be
          >> used as a feed reader, a consumer of the CLI would probably use it
          >> for: bookmarking a collection; refreshing bookmarked collections;
          >> using diff tools to compare local files and then POSTing the output
          >> content to a collection; etc.
          >>
          >> The biggest challenge I face is how the CLI could use the client
          >> environment executables files restfully?
          >>
          >> I need to access the diff tools on the client-side system. Does it
          >> fail any constraints the fact that the CLI would try to access the
          >> diff executable tools under the hood? I would provide to the consumer
          >> the hypermedia controls necessary to fill in the arguments that will
          >> be passed to the executables. Just like HTML forms. What about
          >> code-on-demand instead? The client would executes, as an example,
          >> shell scripting fragment depending on the client environment setup
          >> capabilities. Just like the browser executes JavaScript? It has some
          >> advantages that the client could be partly able to update itself.
          >>
          >> Otherwise I would need to let the server do the diff which will be
          >> retrieve by the client. But the client and the server will most of the
          >> time be on the same machine or local network. The client needs to
          >> access the file system and do operations on files, which the local web
          >> server could do.
          >>
          >> Any advices? Thanks.
          >> -- Philippe
          >>
          >>
          >> ------------------------------------
          >>
          >> Yahoo! Groups Links
          >>
          >>
          >>
          >
        • mike amundsen
          But I don t know at which level it is important or not that the consumer of the user agent knows about those details. if by consumer of the
          Message 4 of 8 , Jun 3, 2012
          • 0 Attachment
            <snip>
            But I don't know at which level it is important or not that the consumer of the user agent knows about those details.
            </snip>

            if by "consumer of the user agent" you mean a _person_, it's always good to let them know what your app "touches", depends upon, etc.

            mca
            http://amundsen.com/blog/
            http://twitter.com@mamund
            http://mamund.com/foaf.rdf#me




            On Sat, Jun 2, 2012 at 5:25 PM, Philippe Rathé <prathe@...> wrote:
            Thanks Mike,

            you are right, I have to make decisions in what concerns the
            architecture of my client but that is not REST related. But I don't
            know at which level it is important or not that the consumer of the
            user agent knows about those details.

            On Fri, Jun 1, 2012 at 10:14 PM, mike amundsen <mamund@...> wrote:
            > Philippe:
            >
            > sounds like an interesting project.
            >
            > first, the REST style focuses primarily on the network-level software
            > details; the implementation within the servers and clients is left open for
            > your own choices.
            >
            > However, Chapter 1 of Fielding's dissertation does a good job of describing
            > the primary software model he had in mind esp. section 1.2[1]. I think
            > you'll find some guidance there and see that your idea of using internal
            > components on the client (i.e. diff, etc.) is well within the scope of an
            > implementation w/ REST characteristics.
            >
            > Hope this helps.
            >
            > [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm#sec_1_2
            >
            > mca
            > http://amundsen.com/blog/
            > http://twitter.com@mamund
            > http://mamund.com/foaf.rdf#me
            >
            >
            >
            >
            > On Fri, Jun 1, 2012 at 7:12 PM, Philippe Rathé <prathe@...> wrote:
            >>
            >> Hello all,
            >>
            >> I would like to code my own atompub client and server. I use atompub
            >> to expose different hierarchical collections of members.I would like
            >> the client being an interactive command line tool. Additionally to be
            >> used as a feed reader, a consumer of the CLI would probably use it
            >> for: bookmarking a collection; refreshing bookmarked collections;
            >> using diff tools to compare local files and then POSTing the output
            >> content to a collection; etc.
            >>
            >> The biggest challenge I face is how the CLI could use the client
            >> environment executables files restfully?
            >>
            >> I need to access the diff tools on the client-side system. Does it
            >> fail any constraints the fact that the CLI would try to access the
            >> diff executable tools under the hood? I would provide to the consumer
            >> the hypermedia controls necessary to fill in the arguments that will
            >> be passed to the executables. Just like HTML forms. What about
            >> code-on-demand instead? The client would executes, as an example,
            >> shell scripting fragment depending on the client environment setup
            >> capabilities. Just like the browser executes JavaScript? It has some
            >> advantages that the client could be partly able to update itself.
            >>
            >> Otherwise I would need to let the server do the diff which will be
            >> retrieve by the client. But the client and the server will most of the
            >> time be on the same machine or local network. The client needs to
            >> access the file system and do operations on files, which the local web
            >> server could do.
            >>
            >> Any advices? Thanks.
            >> -- Philippe
            >>
            >>
            >> ------------------------------------
            >>
            >> Yahoo! Groups Links
            >>
            >> <*> To visit your group on the web, go to:
            >>    http://groups.yahoo.com/group/rest-discuss/
            >>
            >> <*> Your email settings:
            >>    Individual Email | Traditional
            >>
            >> <*> To change settings online go to:
            >>    http://groups.yahoo.com/group/rest-discuss/join
            >>    (Yahoo! ID required)
            >>
            >> <*> To change settings via email:
            >>    rest-discuss-digest@yahoogroups.com
            >>    rest-discuss-fullfeatured@yahoogroups.com
            >>
            >> <*> 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/
            >>
            >

          • Philippe Rathé
            When I m thinking of coding a user agent that run in the shell environment, I m thinking of parsing the representation media-type that I would like to have by
            Message 5 of 8 , Jun 3, 2012
            • 0 Attachment
              When I'm thinking of coding a user agent that run in the shell
              environment, I'm thinking of parsing the representation media-type
              that I would like to have "by default". The reason is that it seems
              practical to have a single media-type for a representation I could use
              for different user agent technologies, such as a browser. I just feel
              that something may be wrong by sending atom feeds to my command line
              client if I want a plain text representation.

              I'm thinking about defining a new media-type specialized for the shell
              environment. Let's call it "application/console" for now. What I think
              could be useful for the command line user agent is having hyper media
              controls, for now just links and forms, separate from the text version
              of a representation. Instead of having an interactive console, just as
              the well known lynx or links browsers command line tool, the shell
              prompt would return between every request. That mean that you would
              have access to your shell. Links for forms from the plain text
              representation would be map to numbers and those numbers would be
              reset at every state transitions to reflect the new possible state
              transitions. It is kind of semi-interactive tool which I think is well
              suited for command line work flow.

              Let's see a possible use case.
              Let's call the tool "foo"
              The lines beginning with # is what could happen under the hood.

              $ foo http://example.org
              # GET /
              # Accept: application/console
              Hello, here is what you could do from here:
              [1]: Read the FAQ
              [2]: Search for documents

              $ foo 1
              # Get /faq
              # Accept: application/console
              [1]: Back to homepage
              Q. two + two
              A. four
              Q. Where can I find help?
              A. Right here

              $ foo 1
              # Get /
              # Accept: application/console
              [1]: Read the FAQ
              [2]: Search for documents

              $ ls -a
              # Just a reminder that you have full access to the shell, the client
              state is saved
              foo.txt ./ ../

              $ foo 2
              Type the name of the document you want to search:
              # Waiting for user input ... and suppose the user type RFC5023 and press enter
              # GET /search?query=RFC5023
              # Accept: application/console
              The Atom Publishing Protocol

              Status of This Memo

              This document specifies an Internet standards track protocol for the
              Internet community, and requests discussion and suggestions for
              improvements. Please refer to the current edition of the "Internet
              Official Protocol Standards" (STD 1) for the standardization state
              and status of this protocol. Distribution of this memo is unlimited.
              ...

              The "text/plain" media type couldn't be used because of the hypermedia
              controls would need to be sent along the text representation, but not
              mixed with the text, just in another section.

              I would really like to have your comments on this idea and the
              possible need for a new media-type "application/console". Please let
              me know if I'm thinking of it wrong and tell me if something was not
              clear.

              Thanks,
              -- Philippe


              On Sun, Jun 3, 2012 at 11:08 AM, mike amundsen <mamund@...> wrote:
              > <snip>
              > But I don't know at which level it is important or not that the consumer of
              > the user agent knows about those details.
              > </snip>
              >
              > if by "consumer of the user agent" you mean a _person_, it's always good to
              > let them know what your app "touches", depends upon, etc.
              >
              > mca
              > http://amundsen.com/blog/
              > http://twitter.com@mamund
              > http://mamund.com/foaf.rdf#me
              >
              >
              >
              >
              > On Sat, Jun 2, 2012 at 5:25 PM, Philippe Rathé <prathe@...> wrote:
              >>
              >> Thanks Mike,
              >>
              >> you are right, I have to make decisions in what concerns the
              >> architecture of my client but that is not REST related. But I don't
              >> know at which level it is important or not that the consumer of the
              >> user agent knows about those details.
              >>
              >> On Fri, Jun 1, 2012 at 10:14 PM, mike amundsen <mamund@...> wrote:
              >> > Philippe:
              >> >
              >> > sounds like an interesting project.
              >> >
              >> > first, the REST style focuses primarily on the network-level software
              >> > details; the implementation within the servers and clients is left open
              >> > for
              >> > your own choices.
              >> >
              >> > However, Chapter 1 of Fielding's dissertation does a good job of
              >> > describing
              >> > the primary software model he had in mind esp. section 1.2[1]. I think
              >> > you'll find some guidance there and see that your idea of using internal
              >> > components on the client (i.e. diff, etc.) is well within the scope of
              >> > an
              >> > implementation w/ REST characteristics.
              >> >
              >> > Hope this helps.
              >> >
              >> >
              >> > [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm#sec_1_2
              >> >
              >> > mca
              >> > http://amundsen.com/blog/
              >> > http://twitter.com@mamund
              >> > http://mamund.com/foaf.rdf#me
              >> >
              >> >
              >> >
              >> >
              >> > On Fri, Jun 1, 2012 at 7:12 PM, Philippe Rathé <prathe@...> wrote:
              >> >>
              >> >> Hello all,
              >> >>
              >> >> I would like to code my own atompub client and server. I use atompub
              >> >> to expose different hierarchical collections of members.I would like
              >> >> the client being an interactive command line tool. Additionally to be
              >> >> used as a feed reader, a consumer of the CLI would probably use it
              >> >> for: bookmarking a collection; refreshing bookmarked collections;
              >> >> using diff tools to compare local files and then POSTing the output
              >> >> content to a collection; etc.
              >> >>
              >> >> The biggest challenge I face is how the CLI could use the client
              >> >> environment executables files restfully?
              >> >>
              >> >> I need to access the diff tools on the client-side system. Does it
              >> >> fail any constraints the fact that the CLI would try to access the
              >> >> diff executable tools under the hood? I would provide to the consumer
              >> >> the hypermedia controls necessary to fill in the arguments that will
              >> >> be passed to the executables. Just like HTML forms. What about
              >> >> code-on-demand instead? The client would executes, as an example,
              >> >> shell scripting fragment depending on the client environment setup
              >> >> capabilities. Just like the browser executes JavaScript? It has some
              >> >> advantages that the client could be partly able to update itself.
              >> >>
              >> >> Otherwise I would need to let the server do the diff which will be
              >> >> retrieve by the client. But the client and the server will most of the
              >> >> time be on the same machine or local network. The client needs to
              >> >> access the file system and do operations on files, which the local web
              >> >> server could do.
              >> >>
              >> >> Any advices? Thanks.
              >> >> -- Philippe
              >> >>
              >> >>
              >> >> ------------------------------------
              >> >>
              >> >> Yahoo! Groups Links
              >> >>
              >> >>
              >> >>
              >> >
              >
              >
            • mike amundsen
              P: I think the notion of a hypermedia console experience is a fine one; I ve cobbled a few together in the past (including using numbers to shortcut the human
              Message 6 of 8 , Jun 3, 2012
              • 0 Attachment
                P:

                I think the notion of a hypermedia console experience is a fine one; I've cobbled a few together in the past (including using numbers to shortcut the human selection process). 

                FWIW, I don't think you MUST invent a new media type for this (even though you MAY want to anyway). I've done this using HTML in the past; even once worked up a CSV style that included hypermedia controls (kinda wonky, but it was fun).

                mca
                http://amundsen.com/blog/
                http://twitter.com@mamund
                http://mamund.com/foaf.rdf#me




                On Sun, Jun 3, 2012 at 3:14 PM, Philippe Rathé <prathe@...> wrote:
                When I'm thinking of coding a user agent that run in the shell
                environment, I'm thinking of parsing the representation media-type
                that I would like to have "by default". The reason is that it seems
                practical to have a single media-type for a representation I could use
                for different user agent technologies, such as a browser. I just feel
                that something may be wrong by sending atom feeds to my command line
                client if I want a plain text representation.

                I'm thinking about defining a new media-type specialized for the shell
                environment. Let's call it "application/console" for now. What I think
                could be useful for the command line user agent is having hyper media
                controls, for now just links and forms, separate from the text version
                of a representation. Instead of having an interactive console, just as
                the well known lynx or links browsers command line tool, the shell
                prompt would return between every request. That mean that you would
                have access to your shell. Links for forms from the plain text
                representation would be map to numbers and those numbers would be
                reset at every state transitions to reflect the new possible state
                transitions. It is kind of semi-interactive tool which I think is well
                suited for command line work flow.

                Let's see a possible use case.
                Let's call the tool "foo"
                The lines beginning with # is what could happen under the hood.

                $ foo http://example.org
                # GET /
                # Accept: application/console
                Hello, here is what you could do from here:
                [1]: Read the FAQ
                [2]: Search for documents

                $ foo 1
                # Get /faq
                # Accept: application/console
                [1]: Back to homepage
                Q. two + two
                A. four
                Q. Where can I find help?
                A. Right here

                $ foo 1
                # Get /
                # Accept: application/console
                [1]: Read the FAQ
                [2]: Search for documents

                $ ls -a
                # Just a reminder that you have full access to the shell, the client
                state is saved
                foo.txt ./ ../

                $ foo 2
                Type the name of the document you want to search:
                # Waiting for user input ... and suppose the user type RFC5023 and press enter
                # GET /search?query=RFC5023
                # Accept: application/console
                The Atom Publishing Protocol

                Status of This Memo

                  This document specifies an Internet standards track protocol for the
                  Internet community, and requests discussion and suggestions for
                  improvements.  Please refer to the current edition of the "Internet
                  Official Protocol Standards" (STD 1) for the standardization state
                  and status of this protocol.  Distribution of this memo is unlimited.
                  ...

                The "text/plain" media type couldn't be used because of the hypermedia
                controls would need to be sent along the text representation, but not
                mixed with the text, just in another section.

                I would really like to have your comments on this idea and the
                possible need for a new media-type "application/console". Please let
                me know if I'm thinking of it wrong and tell me if something was not
                clear.

                Thanks,
                -- Philippe


                On Sun, Jun 3, 2012 at 11:08 AM, mike amundsen <mamund@...> wrote:
                > <snip>
                > But I don't know at which level it is important or not that the consumer of
                > the user agent knows about those details.
                > </snip>
                >
                > if by "consumer of the user agent" you mean a _person_, it's always good to
                > let them know what your app "touches", depends upon, etc.
                >
                > mca
                > http://amundsen.com/blog/
                > http://twitter.com@mamund
                > http://mamund.com/foaf.rdf#me
                >
                >
                >
                >
                > On Sat, Jun 2, 2012 at 5:25 PM, Philippe Rathé <prathe@...> wrote:
                >>
                >> Thanks Mike,
                >>
                >> you are right, I have to make decisions in what concerns the
                >> architecture of my client but that is not REST related. But I don't
                >> know at which level it is important or not that the consumer of the
                >> user agent knows about those details.
                >>
                >> On Fri, Jun 1, 2012 at 10:14 PM, mike amundsen <mamund@...> wrote:
                >> > Philippe:
                >> >
                >> > sounds like an interesting project.
                >> >
                >> > first, the REST style focuses primarily on the network-level software
                >> > details; the implementation within the servers and clients is left open
                >> > for
                >> > your own choices.
                >> >
                >> > However, Chapter 1 of Fielding's dissertation does a good job of
                >> > describing
                >> > the primary software model he had in mind esp. section 1.2[1]. I think
                >> > you'll find some guidance there and see that your idea of using internal
                >> > components on the client (i.e. diff, etc.) is well within the scope of
                >> > an
                >> > implementation w/ REST characteristics.
                >> >
                >> > Hope this helps.
                >> >
                >> >
                >> > [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm#sec_1_2
                >> >
                >> > mca
                >> > http://amundsen.com/blog/
                >> > http://twitter.com@mamund
                >> > http://mamund.com/foaf.rdf#me
                >> >
                >> >
                >> >
                >> >
                >> > On Fri, Jun 1, 2012 at 7:12 PM, Philippe Rathé <prathe@...> wrote:
                >> >>
                >> >> Hello all,
                >> >>
                >> >> I would like to code my own atompub client and server. I use atompub
                >> >> to expose different hierarchical collections of members.I would like
                >> >> the client being an interactive command line tool. Additionally to be
                >> >> used as a feed reader, a consumer of the CLI would probably use it
                >> >> for: bookmarking a collection; refreshing bookmarked collections;
                >> >> using diff tools to compare local files and then POSTing the output
                >> >> content to a collection; etc.
                >> >>
                >> >> The biggest challenge I face is how the CLI could use the client
                >> >> environment executables files restfully?
                >> >>
                >> >> I need to access the diff tools on the client-side system. Does it
                >> >> fail any constraints the fact that the CLI would try to access the
                >> >> diff executable tools under the hood? I would provide to the consumer
                >> >> the hypermedia controls necessary to fill in the arguments that will
                >> >> be passed to the executables. Just like HTML forms. What about
                >> >> code-on-demand instead? The client would executes, as an example,
                >> >> shell scripting fragment depending on the client environment setup
                >> >> capabilities. Just like the browser executes JavaScript? It has some
                >> >> advantages that the client could be partly able to update itself.
                >> >>
                >> >> Otherwise I would need to let the server do the diff which will be
                >> >> retrieve by the client. But the client and the server will most of the
                >> >> time be on the same machine or local network. The client needs to
                >> >> access the file system and do operations on files, which the local web
                >> >> server could do.
                >> >>
                >> >> Any advices? Thanks.
                >> >> -- Philippe
                >> >>
                >> >>
                >> >> ------------------------------------
                >> >>
                >> >> Yahoo! Groups Links
                >> >>
                >> >>
                >> >>
                >> >
                >
                >


                ------------------------------------

                Yahoo! Groups Links

                <*> To visit your group on the web, go to:
                   http://groups.yahoo.com/group/rest-discuss/

                <*> Your email settings:
                   Individual Email | Traditional

                <*> To change settings online go to:
                   http://groups.yahoo.com/group/rest-discuss/join
                   (Yahoo! ID required)

                <*> To change settings via email:
                   rest-discuss-digest@yahoogroups.com
                   rest-discuss-fullfeatured@yahoogroups.com

                <*> 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/


              • Philippe Rathé
                Thanks Mike for taking of your time. The interesting part in creating a new media-type such as application/console is that I was considering coding a generic
                Message 7 of 8 , Jun 3, 2012
                • 0 Attachment
                  Thanks Mike for taking of your time.

                  The interesting part in creating a new media-type such as
                  "application/console" is that I was considering coding a generic user
                  agent specialized in that media-type. Just as browsers are specialized
                  in "text/html". I liked that I could use the user agent for my own
                  project and that it can be easily reused by others to provide out of
                  the box "hypermedia console experience" as you coined.

                  What bring me to this idea is that the command line agent only need a
                  small subset of the metadata if it would parse "application/atom+xml".
                  By example the app:author element which includes FOAF information. On
                  the command line side I don't need it, I only need to display the
                  email.

                  A feature I wanted to have on the command line, was to open the
                  current representation in a browser. The href value of any self link
                  would be pass as argument to the browser executable file. So you could
                  display a richer view with a richer user agent easily. Does it justify
                  the need of "application/console"? I would think yes but maybe they
                  are some cons that I don't foresee. Such as not taking advantage of
                  the cache by having two media types for the same representation.

                  I think I'll do the same as the other folks for now by parsing XTML on
                  the command line agent.

                  -- Philippe

                  On Sun, Jun 3, 2012 at 3:40 PM, mike amundsen <mamund@...> wrote:
                  > P:
                  >
                  > I think the notion of a hypermedia console experience is a fine one; I've
                  > cobbled a few together in the past (including using numbers to shortcut the
                  > human selection process).
                  >
                  > FWIW, I don't think you MUST invent a new media type for this (even though
                  > you MAY want to anyway). I've done this using HTML in the past; even once
                  > worked up a CSV style that included hypermedia controls (kinda wonky, but it
                  > was fun).
                  >
                  > mca
                  > http://amundsen.com/blog/
                  > http://twitter.com@mamund
                  > http://mamund.com/foaf.rdf#me
                  >
                  >
                  >
                  >
                  > On Sun, Jun 3, 2012 at 3:14 PM, Philippe Rathé <prathe@...> wrote:
                  >>
                  >> When I'm thinking of coding a user agent that run in the shell
                  >> environment, I'm thinking of parsing the representation media-type
                  >> that I would like to have "by default". The reason is that it seems
                  >> practical to have a single media-type for a representation I could use
                  >> for different user agent technologies, such as a browser. I just feel
                  >> that something may be wrong by sending atom feeds to my command line
                  >> client if I want a plain text representation.
                  >>
                  >> I'm thinking about defining a new media-type specialized for the shell
                  >> environment. Let's call it "application/console" for now. What I think
                  >> could be useful for the command line user agent is having hyper media
                  >> controls, for now just links and forms, separate from the text version
                  >> of a representation. Instead of having an interactive console, just as
                  >> the well known lynx or links browsers command line tool, the shell
                  >> prompt would return between every request. That mean that you would
                  >> have access to your shell. Links for forms from the plain text
                  >> representation would be map to numbers and those numbers would be
                  >> reset at every state transitions to reflect the new possible state
                  >> transitions. It is kind of semi-interactive tool which I think is well
                  >> suited for command line work flow.
                  >>
                  >> Let's see a possible use case.
                  >> Let's call the tool "foo"
                  >> The lines beginning with # is what could happen under the hood.
                  >>
                  >> $ foo http://example.org
                  >> # GET /
                  >> # Accept: application/console
                  >> Hello, here is what you could do from here:
                  >> [1]: Read the FAQ
                  >> [2]: Search for documents
                  >>
                  >> $ foo 1
                  >> # Get /faq
                  >> # Accept: application/console
                  >> [1]: Back to homepage
                  >> Q. two + two
                  >> A. four
                  >> Q. Where can I find help?
                  >> A. Right here
                  >>
                  >> $ foo 1
                  >> # Get /
                  >> # Accept: application/console
                  >> [1]: Read the FAQ
                  >> [2]: Search for documents
                  >>
                  >> $ ls -a
                  >> # Just a reminder that you have full access to the shell, the client
                  >> state is saved
                  >> foo.txt ./ ../
                  >>
                  >> $ foo 2
                  >> Type the name of the document you want to search:
                  >> # Waiting for user input ... and suppose the user type RFC5023 and press
                  >> enter
                  >> # GET /search?query=RFC5023
                  >> # Accept: application/console
                  >> The Atom Publishing Protocol
                  >>
                  >> Status of This Memo
                  >>
                  >>   This document specifies an Internet standards track protocol for the
                  >>   Internet community, and requests discussion and suggestions for
                  >>   improvements.  Please refer to the current edition of the "Internet
                  >>   Official Protocol Standards" (STD 1) for the standardization state
                  >>   and status of this protocol.  Distribution of this memo is unlimited.
                  >>   ...
                  >>
                  >> The "text/plain" media type couldn't be used because of the hypermedia
                  >> controls would need to be sent along the text representation, but not
                  >> mixed with the text, just in another section.
                  >>
                  >> I would really like to have your comments on this idea and the
                  >> possible need for a new media-type "application/console". Please let
                  >> me know if I'm thinking of it wrong and tell me if something was not
                  >> clear.
                  >>
                  >> Thanks,
                  >> -- Philippe
                  >>
                  >>
                  >> On Sun, Jun 3, 2012 at 11:08 AM, mike amundsen <mamund@...> wrote:
                  >> > <snip>
                  >> > But I don't know at which level it is important or not that the consumer
                  >> > of
                  >> > the user agent knows about those details.
                  >> > </snip>
                  >> >
                  >> > if by "consumer of the user agent" you mean a _person_, it's always good
                  >> > to
                  >> > let them know what your app "touches", depends upon, etc.
                  >> >
                  >> > mca
                  >> > http://amundsen.com/blog/
                  >> > http://twitter.com@mamund
                  >> > http://mamund.com/foaf.rdf#me
                  >> >
                  >> >
                  >> >
                  >> >
                  >> > On Sat, Jun 2, 2012 at 5:25 PM, Philippe Rathé <prathe@...> wrote:
                  >> >>
                  >> >> Thanks Mike,
                  >> >>
                  >> >> you are right, I have to make decisions in what concerns the
                  >> >> architecture of my client but that is not REST related. But I don't
                  >> >> know at which level it is important or not that the consumer of the
                  >> >> user agent knows about those details.
                  >> >>
                  >> >> On Fri, Jun 1, 2012 at 10:14 PM, mike amundsen <mamund@...>
                  >> >> wrote:
                  >> >> > Philippe:
                  >> >> >
                  >> >> > sounds like an interesting project.
                  >> >> >
                  >> >> > first, the REST style focuses primarily on the network-level software
                  >> >> > details; the implementation within the servers and clients is left
                  >> >> > open
                  >> >> > for
                  >> >> > your own choices.
                  >> >> >
                  >> >> > However, Chapter 1 of Fielding's dissertation does a good job of
                  >> >> > describing
                  >> >> > the primary software model he had in mind esp. section 1.2[1]. I
                  >> >> > think
                  >> >> > you'll find some guidance there and see that your idea of using
                  >> >> > internal
                  >> >> > components on the client (i.e. diff, etc.) is well within the scope
                  >> >> > of
                  >> >> > an
                  >> >> > implementation w/ REST characteristics.
                  >> >> >
                  >> >> > Hope this helps.
                  >> >> >
                  >> >> >
                  >> >> >
                  >> >> > [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm#sec_1_2
                  >> >> >
                  >> >> > mca
                  >> >> > http://amundsen.com/blog/
                  >> >> > http://twitter.com@mamund
                  >> >> > http://mamund.com/foaf.rdf#me
                  >> >> >
                  >> >> >
                  >> >> >
                  >> >> >
                  >> >> > On Fri, Jun 1, 2012 at 7:12 PM, Philippe Rathé <prathe@...>
                  >> >> > wrote:
                  >> >> >>
                  >> >> >> Hello all,
                  >> >> >>
                  >> >> >> I would like to code my own atompub client and server. I use atompub
                  >> >> >> to expose different hierarchical collections of members.I would like
                  >> >> >> the client being an interactive command line tool. Additionally to
                  >> >> >> be
                  >> >> >> used as a feed reader, a consumer of the CLI would probably use it
                  >> >> >> for: bookmarking a collection; refreshing bookmarked collections;
                  >> >> >> using diff tools to compare local files and then POSTing the output
                  >> >> >> content to a collection; etc.
                  >> >> >>
                  >> >> >> The biggest challenge I face is how the CLI could use the client
                  >> >> >> environment executables files restfully?
                  >> >> >>
                  >> >> >> I need to access the diff tools on the client-side system. Does it
                  >> >> >> fail any constraints the fact that the CLI would try to access the
                  >> >> >> diff executable tools under the hood? I would provide to the
                  >> >> >> consumer
                  >> >> >> the hypermedia controls necessary to fill in the arguments that will
                  >> >> >> be passed to the executables. Just like HTML forms. What about
                  >> >> >> code-on-demand instead? The client would executes, as an example,
                  >> >> >> shell scripting fragment depending on the client environment setup
                  >> >> >> capabilities. Just like the browser executes JavaScript? It has some
                  >> >> >> advantages that the client could be partly able to update itself.
                  >> >> >>
                  >> >> >> Otherwise I would need to let the server do the diff which will be
                  >> >> >> retrieve by the client. But the client and the server will most of
                  >> >> >> the
                  >> >> >> time be on the same machine or local network. The client needs to
                  >> >> >> access the file system and do operations on files, which the local
                  >> >> >> web
                  >> >> >> server could do.
                  >> >> >>
                  >> >> >> Any advices? Thanks.
                  >> >> >> -- Philippe
                  >> >> >>
                  >> >> >>
                  >> >> >> ------------------------------------
                  >> >> >>
                  >> >> >> Yahoo! Groups Links
                  >> >> >>
                  >> >> >>
                  >> >> >>
                  >> >> >
                  >> >
                  >> >
                  >>
                  >>
                  >> ------------------------------------
                  >>
                  >> Yahoo! Groups Links
                  >>
                  >>
                  >>
                  >
                • mike amundsen
                  PR: yes, there are lots of cool possibilities here. please keep me posted on your progress; this is something that i d like to see more in the future. mca
                  Message 8 of 8 , Jun 3, 2012
                  • 0 Attachment
                    PR:

                    yes, there are lots of cool possibilities here.  please keep me posted on your progress; this is something that i'd like to see more in the future.

                    mca
                    http://amundsen.com/blog/
                    http://twitter.com@mamund
                    http://mamund.com/foaf.rdf#me




                    On Sun, Jun 3, 2012 at 9:35 PM, Philippe Rathé <prathe@...> wrote:
                    Thanks Mike for taking of your time.

                    The interesting part in creating a new media-type such as
                    "application/console" is that I was considering coding a generic user
                    agent specialized in that media-type. Just as browsers are specialized
                    in "text/html". I liked that I could use the user agent for my own
                    project and that it can be easily reused by others to provide out of
                    the box "hypermedia console experience" as you coined.

                    What bring me to this idea is that the command line agent only need a
                    small subset of the metadata if it would parse "application/atom+xml".
                    By example the app:author element which includes FOAF information. On
                    the command line side I don't need it, I only need to display the
                    email.

                    A feature I wanted to have on the command line, was to open the
                    current representation in a browser. The href value of any self link
                    would be pass as argument to the browser executable file. So you could
                    display a richer view with a richer user agent easily. Does it justify
                    the need of "application/console"? I would think yes but maybe they
                    are some cons that I don't foresee. Such as not taking advantage of
                    the cache by having two media types for the same representation.

                    I think I'll do the same as the other folks for now by parsing XTML on
                    the command line agent.

                    -- Philippe

                    On Sun, Jun 3, 2012 at 3:40 PM, mike amundsen <mamund@...> wrote:
                    > P:
                    >
                    > I think the notion of a hypermedia console experience is a fine one; I've
                    > cobbled a few together in the past (including using numbers to shortcut the
                    > human selection process).
                    >
                    > FWIW, I don't think you MUST invent a new media type for this (even though
                    > you MAY want to anyway). I've done this using HTML in the past; even once
                    > worked up a CSV style that included hypermedia controls (kinda wonky, but it
                    > was fun).
                    >
                    > mca
                    > http://amundsen.com/blog/
                    > http://twitter.com@mamund
                    > http://mamund.com/foaf.rdf#me
                    >
                    >
                    >
                    >
                    > On Sun, Jun 3, 2012 at 3:14 PM, Philippe Rathé <prathe@...> wrote:
                    >>
                    >> When I'm thinking of coding a user agent that run in the shell
                    >> environment, I'm thinking of parsing the representation media-type
                    >> that I would like to have "by default". The reason is that it seems
                    >> practical to have a single media-type for a representation I could use
                    >> for different user agent technologies, such as a browser. I just feel
                    >> that something may be wrong by sending atom feeds to my command line
                    >> client if I want a plain text representation.
                    >>
                    >> I'm thinking about defining a new media-type specialized for the shell
                    >> environment. Let's call it "application/console" for now. What I think
                    >> could be useful for the command line user agent is having hyper media
                    >> controls, for now just links and forms, separate from the text version
                    >> of a representation. Instead of having an interactive console, just as
                    >> the well known lynx or links browsers command line tool, the shell
                    >> prompt would return between every request. That mean that you would
                    >> have access to your shell. Links for forms from the plain text
                    >> representation would be map to numbers and those numbers would be
                    >> reset at every state transitions to reflect the new possible state
                    >> transitions. It is kind of semi-interactive tool which I think is well
                    >> suited for command line work flow.
                    >>
                    >> Let's see a possible use case.
                    >> Let's call the tool "foo"
                    >> The lines beginning with # is what could happen under the hood.
                    >>
                    >> $ foo http://example.org
                    >> # GET /
                    >> # Accept: application/console
                    >> Hello, here is what you could do from here:
                    >> [1]: Read the FAQ
                    >> [2]: Search for documents
                    >>
                    >> $ foo 1
                    >> # Get /faq
                    >> # Accept: application/console
                    >> [1]: Back to homepage
                    >> Q. two + two
                    >> A. four
                    >> Q. Where can I find help?
                    >> A. Right here
                    >>
                    >> $ foo 1
                    >> # Get /
                    >> # Accept: application/console
                    >> [1]: Read the FAQ
                    >> [2]: Search for documents
                    >>
                    >> $ ls -a
                    >> # Just a reminder that you have full access to the shell, the client
                    >> state is saved
                    >> foo.txt ./ ../
                    >>
                    >> $ foo 2
                    >> Type the name of the document you want to search:
                    >> # Waiting for user input ... and suppose the user type RFC5023 and press
                    >> enter
                    >> # GET /search?query=RFC5023
                    >> # Accept: application/console
                    >> The Atom Publishing Protocol
                    >>
                    >> Status of This Memo
                    >>
                    >>   This document specifies an Internet standards track protocol for the
                    >>   Internet community, and requests discussion and suggestions for
                    >>   improvements.  Please refer to the current edition of the "Internet
                    >>   Official Protocol Standards" (STD 1) for the standardization state
                    >>   and status of this protocol.  Distribution of this memo is unlimited.
                    >>   ...
                    >>
                    >> The "text/plain" media type couldn't be used because of the hypermedia
                    >> controls would need to be sent along the text representation, but not
                    >> mixed with the text, just in another section.
                    >>
                    >> I would really like to have your comments on this idea and the
                    >> possible need for a new media-type "application/console". Please let
                    >> me know if I'm thinking of it wrong and tell me if something was not
                    >> clear.
                    >>
                    >> Thanks,
                    >> -- Philippe
                    >>
                    >>
                    >> On Sun, Jun 3, 2012 at 11:08 AM, mike amundsen <mamund@...> wrote:
                    >> > <snip>
                    >> > But I don't know at which level it is important or not that the consumer
                    >> > of
                    >> > the user agent knows about those details.
                    >> > </snip>
                    >> >
                    >> > if by "consumer of the user agent" you mean a _person_, it's always good
                    >> > to
                    >> > let them know what your app "touches", depends upon, etc.
                    >> >
                    >> > mca
                    >> > http://amundsen.com/blog/
                    >> > http://twitter.com@mamund
                    >> > http://mamund.com/foaf.rdf#me
                    >> >
                    >> >
                    >> >
                    >> >
                    >> > On Sat, Jun 2, 2012 at 5:25 PM, Philippe Rathé <prathe@...> wrote:
                    >> >>
                    >> >> Thanks Mike,
                    >> >>
                    >> >> you are right, I have to make decisions in what concerns the
                    >> >> architecture of my client but that is not REST related. But I don't
                    >> >> know at which level it is important or not that the consumer of the
                    >> >> user agent knows about those details.
                    >> >>
                    >> >> On Fri, Jun 1, 2012 at 10:14 PM, mike amundsen <mamund@...>
                    >> >> wrote:
                    >> >> > Philippe:
                    >> >> >
                    >> >> > sounds like an interesting project.
                    >> >> >
                    >> >> > first, the REST style focuses primarily on the network-level software
                    >> >> > details; the implementation within the servers and clients is left
                    >> >> > open
                    >> >> > for
                    >> >> > your own choices.
                    >> >> >
                    >> >> > However, Chapter 1 of Fielding's dissertation does a good job of
                    >> >> > describing
                    >> >> > the primary software model he had in mind esp. section 1.2[1]. I
                    >> >> > think
                    >> >> > you'll find some guidance there and see that your idea of using
                    >> >> > internal
                    >> >> > components on the client (i.e. diff, etc.) is well within the scope
                    >> >> > of
                    >> >> > an
                    >> >> > implementation w/ REST characteristics.
                    >> >> >
                    >> >> > Hope this helps.
                    >> >> >
                    >> >> >
                    >> >> >
                    >> >> > [1] http://www.ics.uci.edu/~fielding/pubs/dissertation/software_arch.htm#sec_1_2
                    >> >> >
                    >> >> > mca
                    >> >> > http://amundsen.com/blog/
                    >> >> > http://twitter.com@mamund
                    >> >> > http://mamund.com/foaf.rdf#me
                    >> >> >
                    >> >> >
                    >> >> >
                    >> >> >
                    >> >> > On Fri, Jun 1, 2012 at 7:12 PM, Philippe Rathé <prathe@...>
                    >> >> > wrote:
                    >> >> >>
                    >> >> >> Hello all,
                    >> >> >>
                    >> >> >> I would like to code my own atompub client and server. I use atompub
                    >> >> >> to expose different hierarchical collections of members.I would like
                    >> >> >> the client being an interactive command line tool. Additionally to
                    >> >> >> be
                    >> >> >> used as a feed reader, a consumer of the CLI would probably use it
                    >> >> >> for: bookmarking a collection; refreshing bookmarked collections;
                    >> >> >> using diff tools to compare local files and then POSTing the output
                    >> >> >> content to a collection; etc.
                    >> >> >>
                    >> >> >> The biggest challenge I face is how the CLI could use the client
                    >> >> >> environment executables files restfully?
                    >> >> >>
                    >> >> >> I need to access the diff tools on the client-side system. Does it
                    >> >> >> fail any constraints the fact that the CLI would try to access the
                    >> >> >> diff executable tools under the hood? I would provide to the
                    >> >> >> consumer
                    >> >> >> the hypermedia controls necessary to fill in the arguments that will
                    >> >> >> be passed to the executables. Just like HTML forms. What about
                    >> >> >> code-on-demand instead? The client would executes, as an example,
                    >> >> >> shell scripting fragment depending on the client environment setup
                    >> >> >> capabilities. Just like the browser executes JavaScript? It has some
                    >> >> >> advantages that the client could be partly able to update itself.
                    >> >> >>
                    >> >> >> Otherwise I would need to let the server do the diff which will be
                    >> >> >> retrieve by the client. But the client and the server will most of
                    >> >> >> the
                    >> >> >> time be on the same machine or local network. The client needs to
                    >> >> >> access the file system and do operations on files, which the local
                    >> >> >> web
                    >> >> >> server could do.
                    >> >> >>
                    >> >> >> Any advices? Thanks.
                    >> >> >> -- Philippe
                    >> >> >>
                    >> >> >>
                    >> >> >> ------------------------------------
                    >> >> >>
                    >> >> >> Yahoo! Groups Links
                    >> >> >>
                    >> >> >>
                    >> >> >>
                    >> >> >
                    >> >
                    >> >
                    >>
                    >>
                    >> ------------------------------------
                    >>
                    >> Yahoo! Groups Links
                    >>
                    >>
                    >>
                    >


                    ------------------------------------

                    Yahoo! Groups Links

                    <*> To visit your group on the web, go to:
                       http://groups.yahoo.com/group/rest-discuss/

                    <*> Your email settings:
                       Individual Email | Traditional

                    <*> To change settings online go to:
                       http://groups.yahoo.com/group/rest-discuss/join
                       (Yahoo! ID required)

                    <*> To change settings via email:
                       rest-discuss-digest@yahoogroups.com
                       rest-discuss-fullfeatured@yahoogroups.com

                    <*> 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/


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