Design is really about distilling the essential form and function to solve a problem space. Once the problem space is known - sometimes the design just pops out. After a lot of effort, thankfully, the design for Globs is starting to squeeze out.
During the design phase I've constantly moved up and down the following axis:
- big vs small
- fast vs slow
- consistent vs eventually consistent
- complexity vs simplicity
- private vs public
- flow vs interruption
- creation vs copying
- usability vs utility
- XML vs JSON vs RPC vs HTML5
- universal vs limited
- and many more ....
I'm still moving the sliders on each of these dimensions - but here is what I know so far:
- a Glob is a handle on a Thing - it is not the Thing itself - it just sticks to it
- a Glob belongs to a Channel
- a Glob has a URI in that Channel
- a Glob is idempotent (we need this for calculating Karma++)
- each Glob has an external SHA1 and an internal SHA1
- a Glob has a summary, favicon, text icon, origin context, captured_on_time and given_to etc.
- a Glob has a HTML5 Description/Payload
- a Description contains actions on the underlying Thing
- Channel, Context and Configuration variables can be inserted into Glob placeholders
- Globs can be HTTP POSTed into the Trail of a Channel via a Sensor
- Globs can arrive in the Trail in absolute time or relative time (including the future)
- A Glob can be proxied from one Channel to another Channel
Along the way here are some ideas that were ruled out:
- using Git as the Glob store
- a Glob does not contain code itself (although it can anchor some code)
- a Glob-specific templating language
- tying Globs to a specific programming language or web framework
- storing Globs in XML, JSON or YAML etc
So there you have it: each Channel contains a Trail of Globs which the user can traverse from the past into the future while performing actions via the Globs stuck to the underlying Things. The speed of action, while scoring karma points, with directed focus will hopefully lead the user to a state of flow.
