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

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é <[email protected]> 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 <[email protected]> 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é <[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
> >>
> >>
> >>
> >
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>