Re: How a CLI could use the client environment executables files?

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é <[email protected]> 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 <[email protected]> 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é <[email protected]> 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 <[email protected]>
> 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é <[email protected]>
> 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
>
>
>
>