|About All Things...|
Publish / Subscribe
|...taking programming beyond:|
Threads, Message Queues, Client-Server, CORBA, Web Services, SOAs, Agents, Synchronous Architectures, Imperative Programming - and even Applications, Desktops and Documents
|...works for ThoughtWorks UK; originally from April 2002 to July 2007 and now recently re-joined. Previously worked as a Web Architect for the Financial Times.|
|...went to both UCL and Imperial College of the University of London (in the Eighties); specialising in Logic during his MSc.|
|...wonders when his LinkedIn Account will be useful|
|...has a phone-cam, and used it on himself once, just before his weekly shave:|
|...can be contacted by
and followed on Twitter.
March 1, 2014 11:24
After filling up that other
blog recently with 61
pages of content, one page a day, I was challenged by my ThoughtWorks colleague,
Andy McWilliams, to help him get in more
easily to my explanations of the Object Network applied to Augmented Reality and the
Internet of Things, especially around how my approach differs and is better than other
Here's the short overview I came up with:
Broadly-speaking, existing approaches to unifying the IoT
The Thing System,
Argot, ..) are built around event and action messages. Messages are
often managed through a message bus and/or an API that gives message construction and a
function-call and callback interface, perhaps through socket connections.
Programming is offered through "event-action" (or "callback-call") rule programming,
If This Then That.
The Object Network Approach
The Object Network, on the other hand, is built like the Web,
using URLs. These URLs point not to Web pages but to JSON state objects. Any peer can
publish state objects on URLs - e.g. sensors, controllers, mobile devices, servers,
etc - and that state can be pulled or pushed at any time between peers using HTTP GET and
POST (or CoAP!).
Object Network programming is based, not on events and messages, but on state and state
transfer. So instead of event-action rules, it has "state-to-state" rules, which are
simpler and more powerful. Actions, if needed, are handled by creating "intent objects",
but peer objects are very much more empowered and independent, so can run their own
rules to set their own state in the face of surrounding state objects observed through
Three Object Net Posts
I then pointed Andy at one of the posts on that other blog, but here are three posts there that are relevant:
Benefits of The Object Net Approach
These posts give more elaboration around the benefits of this approach, but briefly:
Using URLs is a force towards harmonisation of the formats they are contained in - each
end of the link will tend to come from the same family of formats. So simply putting
URLs in JSON is itself a massive benefit, if it leads to common formats for the same
data. Further, these links and shared formats, when used across multiple systems, form a
"fabric" of data that can be used to serendipitously create whole new applications and mash-ups.
It's a simple and powerful distributed systems model, as the Web itself has
demonstrated. When it becomes peer-to-peer and asynchronous through CoAP, IPv6 and the
IoT, its power increases further through timeliness and interactivity, decentralisation
and the removal of intermediaries - and puts that power in the hands of users in their
intimate daily lives.
To this the Object Net adds the simple and powerful programming model of setting object
state as a function of surrounding neighbour, environmental or public object states,
observed through links. The key aspect is the autonomy of each object in the network to
determine its own state evolution in a decentralised, loosely-coupled mesh.
Now, merely using the
stack buys you most of the above approach, being
chartered from the start with REST in mind, plus adding
asynchronous resource observation
and having great peer-to-peer potential
through IPv6 and UDP.
So really, it all depends on the code that uses it - does it build the observation model
into the programming model like the Object Network does? Does it simply let you describe
how the state of your object can be set according to the states of objects you link to
and observe? Does it talk about common data formats? I've yet to track down a framework
or platform that does this.
The nearest I've seen to an approach that has many of the elements of this, including
observation through CoAP and a model layer above, is the
Open Source Internet of Things
(and see here also). This project seems to be
much more complex, partly due to its being based on the Semantic Web.
I'll be exploring how the Object Net compares to it and the overall CoRE
approach in the next post here, and maybe also see how the
and other initiatives
fit in to all that.
January 27, 2014 11:36
I've started another blog called Building The Object Network, about how I'm experimenting with Augmented Reality for the Internet of Things using the Object Network approach.
So far I've been blogging every day.
January 16, 2013 17:09
Well that worked out pretty well:
I have a 3D environment on Android programmed in a simple but powerful declarative
language which I've called "Cyrus".
Cyrus basically uses JSON all the way through: from user
interface and scene graph to rewrite rules, on the wire and on disk. The Cyrus
programming language is essentially JSON itself, as JSON rewrite rules. I've reduced the
noise of JSON in Cyrus by taking out redundant double-quotes, square brackets and
commas. It looks very nice to me.
August 17, 2012 11:11
If you also think that hacking up 3D worlds on Android could be fun, then join me! Stuff you should expect to play with if you want to get involved includes Java, Android, OpenGL ES 2.0, 3D model creation, hyperlinked JSON and JSON rewrite rules. Creatives, evangelists and inspirers are also very welcome to get involved!
The idea is to make an app (NetMash) that lets people build, mash up, animate and program 3D worlds, shared online and all linked-up, Web-like.
Like creative-mode Minecraft, but adding easy in-world programming and shared online by default. Or maybe a bit like an open, distributed, generic, mobile
here), for adults as well as children.
NetMash is intended to deliver creative empowerment to ordinary people. We professional software folk often get stereotyped as geeks, and the creative fun we often have dismissed as in some way unusual. That's a real shame, because such prejudice means that the other 99.9% of the world are simply missing out on the joy of experiencing the most creative and empowering activities humankind has yet invented.
August 15, 2012 11:37
I just re-read my article on the Universe Web. I think it's pretty good. Indeed, to be honest, "programming as Cyberspace building" is where my heart has always been, and I'm all about following my heart this year. Especially if it's more fun, for both myself and others! Or if it opens up new worlds to new people.
In contrast, I don't see "fun" in W3C or IETF activities. Indeed, there's recently been a number of examples of tension in that world, between stabilisation and innovation, idealism and pragmatism, Enterprisey and Webby. Interestingly, all those examples have a "2.0" flavour: HTML5 (Web 2.0), HTTP 2.0 and OAuth 2.0.
My own interests are rough consensus and running code; innovation and pragmatism. Webbiness not in the W3C sense - "Web" Services, Semantic "Web", "Web" Sockets, etc. - but in the sense of "the simplest thing that works". Which is the Web of HTTP (1.1), URLs, JSON and REST, or specifically my FOREST interpretation.
I crave the simple and powerful, the cool and the fun. Which ultimately leads to the kind of thing I was describing as the Universe Web. And to be honest, I'd like to write and code for me, not for my peers and colleagues or for my career.
So, to the pursuit of pure joy in place of compromise, I'll now be focusing my energies on the journey of evolving the NetMash Java server and Android app towards an online, open, hyperlinked virtual world that is programmable in-world by users using simple rules.
January 20, 2012 18:07
Updated: January 23, 2012 19:45
Right, let's get started with some basic conventions in the Object Network!
This part in the Object Network series
will cover URLs, HTTP headers and some common JSON patterns.
Updated 23/1/12: I changed the URLs in the example to have one of each type.
January 19, 2012 20:58
Updated: January 22, 2012 16:05
OK, I'm trying to take a Big Idea and make it as Simple As Possible to grasp.
If we link our JSON data together and use the same formats, then our mobile, browser and
server apps can become much simpler - through clean, stable, common, shared, re-used
code - and much more powerful - through clean, stable, common, shared, linked, cached data.
This is the second part in the
Object Network series,
which will guide you away from building isolated Web APIs to engaging in a linked-up data landscape.
November 29, 2011 23:11
Updated: January 22, 2012 16:03
It's interesting to compare the
current growth of Web APIs
with the early growth of the Web itself.
To save you jumping those links: the Web dramatically beats the APIs.
I believe that the most likely cause of such relatively slow growth (in what should be a
booming ecosystem) is that each API forms a closed silo and cannot benefit from any
network effects. Every API is different and there are no links between them. There
usually aren't any links within a silo. You can't even use a given API without first
consulting the documentation.
The Object Network is designed to fix this, with linked-up
JSON in common formats. This will allow easier mashing, sharing and cacheing of data and
allow client code to be shared and reused.
May 10, 2011 11:11
The Web, in its purest form - declarative HTML and CSS documents, XML feeds - is
mashable, linkable, sharable. It's easy to create documents that slot into the global
Web and can be accessed on any device; accessed by just a simple link. Servers can
easily scale through statelessness and cacheing.
Native Mobile Apps are fast and slick. They are intimate with the dynamic, interactive,
tactile mobile user interface, intimate with the capabilities of the device and intimate
with the domain of mobile: photos, locations, contacts, messages.
OTS is a simple, clean, powerful approach to delivering Mobile functionality and
content that is designed to realise these benefits of both Native Apps and the Web.
May 6, 2011 11:11
Like Subbu, I also have been sitting on a blog post
about the Richardson Maturity Model.
I have different reasons for feeling uncomfortable with this Model, however.
The following came out of a discussion on an internal list at ThoughtWorks, where a
number of people were talking about how they aspired to reach the "Holy Grail" of REST
Level 3, and still thought they were basically "doing REST" by addressing most of the
But, as indeed pointed out in that article, REST is only at Level 3.
However, fortunately, you can jump right to Level 3 without much effort.
May 5, 2011 12:16
This post is a response to a question that came up on an internal ThoughtWorks list.
The question was, in summary: "Is using JSON more RESTful than minting our own
Media Types as required, given that using raw JSON means reading inside the content in
order to know what type is being transferred?"
TL;DR: Yes, use a common Media Type and "switch" on the internal data type; create a
new Media Type only when something generic and broad and new and useful settles out.
Seems controversial to you? Read on...
February 12, 2011 14:07
Here's a quick catch-up of developments in FOREST.
I've been working much more on FOREST than Fjord or JSON-Mash recently, and it's coming along very nicely.
Actually, I've been lying flat out in bed with Pneumonia (and various other consequent ailments) for several weeks, so have been quietly tip-tapping away on a laptop resting on my tum, when I've had the energy.
Which has given me a chance to tidy up and finish off some FOREST stuff that I started last year...
March 18, 2010 16:58
Around the middle of February I completed a basic persistence and networking
then had to do other things for a month. Just recently I
fixed Fjord to work with the latest version of the
Next project: I'm going to use Fjord in a Web Framework to be called "JSON-Mash".
I intend to show that JSON-Mash will be a great framework for rapidly building
truly interoperable and truly scalable online and distributed functionality.
Here's how JSON-Mash will work.
January 26, 2010 13:46
Right, I'm pleased to say that I've now implemented enough of the
on Node.js to be able to run the
that I introduced it with. As yet, this runs in memory only - i.e., no disk, no
Here's the code on GitHub with tests
that show how it works. The language has changed a little so I'll show the example here
again, copied over from the test code, in order to explain the differences.
January 6, 2010 17:03
Well, I've put together the first few lines of Fjord, implemented on Node.js.
Here's the description on GitHub: Fjord is a language for expressing domain logic as match-rewrite functions over mashable JSON Web objects.
I'm developing Fjord very openly, in the hope someone out there will be interested in getting involved in helping guide its design and implementation. I suppose code speaks louder than blog posts.