Hack day
The hack day will center around a new [media type](Work order) designed for machine-to-machine interactions. The work order media type is pretty generic in nature, and falls under the domain of "workflow" or "job control". We will create robots that perform various tasks on behalf of the server that passes out work as it becomes available.
This Work Order media type describes "work that needs to be done, and what to do when you're done". When an agent receives a document of this type, it may find among other things:
- what needs to be done
- any information about the work that needs to be done
- how progress about the work can be reported
- how to indicate that work has been completed
In order to achieve machine-to-machine hypermedia, the media types and affordances need to be laid down so that messages can be exchanged and understood.
Just like browsers understand HTML and CSS and so on, a machine-to-machine agent needs to understand certain media types minted for machine work. An example of this is Collection+JSON which allows machine clients to understand collections of things, and even manipulate them.
In this hack day we will be working with a media type which describes "work that needs to be done". The type of work itself is not defined in the media type definition; just as Collection+JSON doesn't specify what things are in the collection, be they blog posts or line items. The work can be anything, like deploying some code, shutting down a server or tweeting a message.
(hopefully) We have a functioning server that has a collection of work waiting to be performed. In this hack day we hope to get several agents that can perform some of the work, and maybe other servers that might provide other types of work too.
It would be cool to have the attendees write small workers that can do various things like play sounds on their speakers, or take a photo with a webcam, or do face recognition on photographs; whatever the attendees can do with their computers, and have servers that pass out work to these agents as it sees fit.
To do this, a simple server has been created that can add work to various queues. The main work that needs to be done on the hack day is to define different types of work with their inputs and outputs; not very hard.
The hack day resulted in quite a few robots and work item types:
- Prompt a human for some text input
- Play a wav-file impl
- Read a word / sentence out loud
- Create maths problems impl
- Show a youtube clip based on a search word
- Send an e-mail
- Take an order for a cup of coffee
- Match lyrics from a song
- Translate a word/sentence from one language to another
- Call a phone number and read a sentence out loud
- Read a word / sentence out loud using a localized voice
- Download and transcode a video file into HTML5 capable video and upload it somewhere
During the hack day we wired some of these workers together to form (albeit simple) workflows. Most of these involved asking a human for input, since coordinating workers to be available for a big bang demo would have stolen too much time.
- Input → Youtube searcher: An input robot prompts for a YouTube search text, which is fed to the youtube searcher. The searcher (different robot) then displays a video.
- Input → email: An input robot prompts for an e-mail address, which is added to an e-mail work item. The email robot then sends that email a little hello world email.
- Input → maths: An input robot prompts for the desired difficulty, which is added to a math work item. The math robot sees this and makes a maths problem, and its solution.
- Input → wav: An input robot prompts for a URL of a wav file, which is added to a play sound work item. A play sound robot then sees this and plays the sound.
(more examples to come)
It would also probably be useful to have a few simple workers written in JavaScript in a browser, and have all the attendees open up workers on their phones, laptops, tablets, and see the result; this should probably be done at the beginning, to ensure that the attendees have something to tinker with so that they can grasp the architecture of it all, even the non-coders out there; they can see the exchanges go back and forth, and help grasp why all of this is happening.
At the moment there is no server that implements this; but it shouldn't be too hard to whip one up before REST Fest, at least one that provides the MUSTs.
An additional piece of this problem domain is that of deciding what work goes into what queue.
Traditional thinking might lead to an implementation where the server does all this, thus introducing the semantic coupling between the agents and the server. A better and more decentralized idea is to build upon the notion of workers, and introduce a similar media type which deals exclusively with the assignment of work. This allows a "decision maker" agent to literally be in control over the other "worker agents" by instructing the server about what work should be in what queues, based on what work completes where and so on.
This would allow the agents to again be decoupled from the server components (since the servers wouldn't know what on earth "send a tweet" is), and keep the coupling between agents.
to be continued
- Ruby Work Order Worker library with examples
- Dynamic work order server in erlang
- Massively Multiplayer Music Player — workers that play five second snippets of a song
- Coffee ordering robot
- Text-to-speech robot
- Scala sound playing robot