Application 'Player'

[landlessness]

Powerful metaphor for client side of HATEOAS:

Application 'Player'
http://vikasjee.wordpress.com/2012/04/30/where-is-my-application-player/

[Steven WIllmott]

Useful way of thinking about this. In a way today's "application player" is the web browser (renders content, renders controls like next, create, destroy, auth, …) but it's both too complex (in some contexts you have a lot of controls you don't need) and too limited (you can can't create a custom enough interface to "play" some applications) and you can't interact (well) with native resources.

[Mike Kelly]

I recently started working on a 'browser' for hal+json which will make
any HAL-driven API 'surfable'. It's a work in progress but hopefully
it's early incarnation can give you some idea of where I am headed
with this.

demo: http://hal-shop.heroku.com/hal_browser.html

code: https://github.com/mikekelly/hal-browser

Cheers,
Mike

--
Mike

http://twitter.com/mikekelly85
http://github.com/mikekelly
http://linkedin.com/in/mikekelly123

[mca]

it's good to see this kind of thinking and these kinds of questions.
the more talk we have about this "application player" the more likely
we are to discuss what it would take to make such a thing possible;
compare that vision to what we currently do; and have the opportunity
to modify our current practices in attempts to get closer to the
vision.

IME over the last couple years in this space, i've dome to the POV
that any "players|browser|client" that is powerful "enough" to support
an application (problem) domain requires:
1) the ability of a sender( server) to sufficiently express
domain-specifics in a message
2) the ability of a recipient (client) to recognize, parse, and (where
appropriate) activate both data and transition controls within the
message

this all hinges on the richenss/power of the _messages_ being passed around.

anything that is missing in the message must be compensated for in the
recipient coding. for example, messages that contain only "raw data"
(think CSV) require all problem-domain details for interpretation and
transitions to be coded into the client (possibly by shipping
code-on-demand). as more problem domain specifics are added into the
message, less coding is required on the recipient side.

on a similar note, the more problem domain specific coding in the
client, the more "tightly bound" the recipient is to a particular
sender; the more likely changes in the message (raw data) will "break"
the code on the recipient.

an "ultimate" message is one that requires no problem-domain specifics
to be coded into the client. the result is a generic application
player|browser|client that experiences zero domain-specific binding to
a particular server.

IME, most of my customers call me because they continue to rely on
"dumb messages (i.e. raw data) and "smart clients" (i.e. lots of
problem-domain specific coding) which continues to enclose the
recipient in a tightly-bound grip of a particular server. what i do is
help them loosen this grip. i do it by helping my customers create
"smarter messages" (more hypermedia) and "dumber clients" (less
domain-specific code) and, as a result, enabling a "greater range of
motion" in their application implementation over time.

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

[Terren Suydam]

It seems to me though that a "generic application player" (assuming a
messaging framework robust enough to enable this) runs head first into
a usability dilemma.

On the one hand, the client cannot make any assumptions about what
kinds of transitions are available beforehand. On the other hand, the
client is the interface to the user, and good interfaces are hard. At
the very least they demand domain-specific knowledge that informs the
best way to present controls in a way that works with human
psychology.

With HTML, the server handles the interface *and* the transitions. I
think if a generic application player were to ever become a reality it
would entail either:

- the API also serving the interface (layout) a la HTML
- strong AI on the client :-]

Terren

[mca]

the baseline assumption i've been operating on is to change the
interaction model to be more "appropriate" for machine clients instead
of trying to get machine clients to "behave like a human."

this means my media type design is different for machines than for
humans. the mapping of the problem domain to HTTP is different when
dealing w/ machines. the number of link choices is greatly reduced
(i.e. only one option in most cases) and the process for handling
arguments (i.e. HTML.FORM) is done differently.

the result in my early testing has been implementations of machines
that can successfully navigate a variable set of links in order to
reach a goal. IOW, the machine is able to deal w/ a limited set of
modifications to the link path as long as the end goal is still
"available." and, so far, i've not needed to rely on "AI" for this;
just the ability to recognize identifiers (no entailment, no
deduction, etc.).

i've posted a couple trivial examples on github:
https://github.com/mamund/miss-grants-controlller
https://github.com/mamund/m2m-no-fail-form

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

[Jørn Wildt]

I really like that "dumb data, smart client" vs. "smart data, dumb client". That is a simple Way to explain REST to normal people. Is that your saying or do you have source to quote for it?

/Jørn

[Ed Anuff]

which one is REST?

[Mike Kelly]

Either, really - it depends on the nature of the clients you are targeting

[Darrel Miller]

On Fri, May 4, 2012 at 6:15 PM, Ed Anuff <e...@anuff.com> wrote:
> which one is REST?
>

REST works really well for dumb clients and smart data. In private I
like to describe my clients as pretty, but dumb :-)

Darrel

[mca]

the "dumb client/smart data" meme is something i've used for a few
years as a "hook" - a way to get folks to think a bit. IRL, it's too
simplistic (as Mike Kelly already pointed out).

for example, I do a training exercise for those working on message
design that starts w/ a "raw message" for a human-driven client app:
<list>
<user>
<id>123</id>
<name>Mike</name>
<email>mam...@yahoo.com</email>
</user>
...
</list>

with a custom client that knows how to:
- construct URIs
- add, update, delete records
- search records
You could call all the above" out of band" knowledge since it does not
appear _in_ the message (in band)

gradually, through design and coding exercises, each of these
"hard-coded" parts of the client are removed
- no more URI construction,
- no more hard-coding on how to create a payload, which method to use,
which URI to use, etc.,
no more hard-coding to create a valid search request
this hard code is replaced by code that recognizes affordances and
interprets them accordingly.

eventually the code and the message look quite different:
<list>
<query rel="search" href="...">
<field id="name" value="" />
</query>
<new href="...">
<field id="name" value="" />
<field id="email" value="" />
</new>
<item href="...">
<field id="name">Mike</field>
<field id="email"l>mam...@yahoo.com</field>
</item>
...
</list>
You could say that there is more information "in band" now (in the
mesasge) and less "out of band" (in the client)

as a "kicker", the last step in the exercise is a server that produces
an entirely new set of fields and affordance details using the same
message design. A well-built client will work just fine when it
encounters this new "in band" information.
<list>
<query href="..." rel="search">
<field id="country" />
</query>
<new href="...">
<field id="country" value="" />
<field id="continent" value="" />
<field id="hemisphere" value="" />
</new>
<item href="...">
<field id="country" value="Brazil" />
<field id="continent" value="South America" />
<field id="hemisphere" value="Southern" />
</item>
...
</list>

so, as the message gains "smarts" the client loses some code (and
domain-specific bits) but the client also gains some new code that
"binds" to the media type and it's affordances.

The example is somewhat trivial, but when you apply this pattern to an
entire problem domain, the gains can be substantial.

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

[Jørn Wildt]

I was saying smart data / dump clients is a simple way to explain REST to
people - not "REST is only smart data / dumb clients". But Mike A. explains
it quite well below, thanks.

Anyway - I was testing this way of explaining REST (parts of it, okay,
mainly hyper media) to some folks at work - and it is something they
immediately buy into without having me to explain what hyper media
affordances are.

/J�rn