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

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