Skip to content

Instantly share code, notes, and snippets.

@timshadel
Last active December 18, 2015 01:49
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save timshadel/5707001 to your computer and use it in GitHub Desktop.
Save timshadel/5707001 to your computer and use it in GitHub Desktop.

So the brilliance of hypermedia is that it's a protocol programming language: the client is the generic execution environment, and the server is the "programmer" which sends tiny little chunks of programs down to the client to dictate what actions may be taken next, given its context.

The fact that the client also builds a UI is irrelevant to this power. The power is in creating a dynamic, custom protocol by choosing for the client which message structures that will be sent from the client, which is done using merely the tools of hypermedia. The protocol between a client and server is then codified in the hypermedia (e.g. HTML) part of the code which uses links and forms to document the various messages which may pass between client and server, and the client states in which either may be used.

Armstrong's formula for a good protocol:

Client-State, Client-Message => Server-State, Server-Response-Message

But in hypermedia, the server's response dictate's the client state:

      +----------------- Select a valid message ----------------+
      |                                                         |
      V                                                         |
Client-Message => Server-State, Server-Response-Message => Client-State

This is a naive view of the web; one in which the client always obeys the server, and one in which the server only ever sends valid message templates to the client, and where the client has no Back button in their browser, no browser extensions, and no way in which to send bad messages which corrupt the Server-State, and thus the Client-State by it's close connection.

Still, we can hold to the basic model:

Server Response  ==>     Client    ==>  Client State

 Program Script  ==>  Interpreter  ==>  Program Output

But the amazing thing is that hypermedia has always been a program-writing program! It's output is another "program" of messages which will advance the Server State in a known way, without any prior knowledge coded into the Client "Interpreter".

 Program Script  ==>  Interpreter  ==>  Server-Executable "Mini-Programs"

 Client-Message  ==>    Server     ==>  Server-State

So, drawn another way, we have a perpetual motion machine:

Client-State <-- Client  <--  Server-Response-Message  <--  Compile a list of valid
      |                                                     "mini-programs" for this state
      |                                                                ^
      V                                                                |
Select a valid message,  ==>  Client-Message  ==>  Server  ==>  Server-State
involve humans or apps

While some of these "Mini-Programs" don't take any arguments (e.g. links), some of them do. And this is where the emergent behavior of the web comes in, since now the client can enlist humans, scripts or any other helper in deciding which inputs to use when executing those "Mini-Programs" on the server. The web, in effect, is a cooperative, multi-agent programming platform.

And that is why hypermedia matters a whole lot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment