Mobiles are unique - if you want to miss out on the opportunity they represent, you could choose to see them as just slow computers with tiny interfaces and dodgy Internet connections. Then try to squeeze in your traditional applications; try squeezing the office desktop metaphor with its sedentary documents into a device the size of a mouse!
Alternatively, see them as the most personal, social and dynamic of devices that are becoming connected to the Internet. Now a multi-billion-scale global opportunity opens up to you. That's customers and dollars! In trying to grasp this, some are calling it 'Mobile 2.0', by analogy with its sibling, Web 2.0.
In that light, the Killer App for Mobile 2.0 is the sharer, masher and updater of People, Things, Times and Places... The key to getting Mobile 2.0 right is for it to merge seamlessly into our lives. That means the handling of dynamic and shared data becomes the top priority, even above the handling of applications.
This article describes a Mobile 2.0 platform that makes people and their stuff first class - not applications. ...
Mobiles are unique - if you want to miss out on the opportunity they represent, you could choose to see them as just slow computers with tiny interfaces and dodgy Internet connections. Then try to squeeze in your traditional applications; try squeezing the office desktop metaphor with its sedentary documents into a device the size of a mouse!
Alternatively, see them as the most personal, social and dynamic of devices that are becoming connected to the Internet. Now a multi-billion-scale global opportunity opens up to you. That's customers and dollars! In trying to grasp this, some are calling it 'Mobile 2.0', by analogy with its sibling, Web 2.0.
In that light, the Killer App for Mobile 2.0 is the sharer, masher and updater of People, Things, Times and Places... The key to getting Mobile 2.0 right is for it to merge seamlessly into our lives. That means the handling of dynamic and shared data becomes the top priority, even above the handling of applications.
This article describes a Mobile 2.0 platform that makes people and their stuff first class - not applications.
Mobile 2.0 should be about effortless delivery of dynamic data such as local weather, personalised news feeds, timelines off Facebook and feeds off Twitter, messages, notes, videos, photos, calendar entries, map locations and meetup plans.
Mobile 2.0 should easily allow us to two-way-share this dynamic data with family, friends, contacts, third parties and the world.
People don't actually want applications on their mobiles!
What Mobile 2.0 does not need is traditional applications, because applications just get in the way of this sharing, mashing and updating of live and personal data. What most people want on their mobiles is not the applications, but the stuff they animate.
People only accept the concept of applications (whether a native app or a Web app) because that's all they've been offered, and it's largely good enough. But no-one actually wants to download and launch and register and log in to a local find-your-friends application - they just want to find their friends in the area - now! And they shouldn't then have to flip between the find-your-friends map owned by that application and the restaurant review map owned by another.
They don't want Facebook videos and YouTube videos and phone videos. They just want to share videos. They shouldn't have to think about whether to send a picture by MMS or to use an upload app, after remembering the login. They don't want multiple ways of sending messages: IM, SMS, Twitter, Facebook, etc. They shouldn't have to think about how to tell their friends about some news item - whether to post a TinyURL link on Twitter or copy the text manually into Facebook.
They only want one shared calendar, not the phone calendar and a Google calendar and events on Upcoming.org, that need two more logins. They shouldn't have to think about how to synchronise music or contacts lists on the phone, the iPod, the PC, some memory card and online.
Applications - both native and Web, and including Applets and Widgets - just get in the way of life! They try to own or control our People, Things, Times and Places, breaking them up with arbitrary application boundaries and making things unnecessarily hard to do.
People just want to share new stuff through their mobiles
What most people would prefer is for their friends and messages from their phonebook, their Facebook, their Twitter, their IM, plus their Flickr photos, their Facebook photos, their restaurant and film reviews and their meeting places all to appear on the same map or in the same calendar... along with the local weather forecast for now and for any dates being planned.
And for that map or calendar, those photos, messages, interesting news, etc., to be actively shared amongst those friends, or even the entire world, simply by flicking the 'share with friends' or the 'make public' switch. Any member of a group should be able to post photos into a shared gallery, or scribble onto a shared whiteboard.
The Killer App for Mobile 2.0 is the sharer, masher and updater of People, Things, Times and Places. This Mobile 2.0 platform would seamlessly merge, update, synchronise, upload, download and save your latest life stuff, including that of your friends and family, so that you no longer have to think about doing it yourself.
Your identity and your stuff would be owned and controlled by you through your personal handset. They would not be merely transferrable - they'd simply be transferred, to where they're needed, when they're needed, using an open Internet protocol and standard formats.
What this Mobile 2.0 platform must do
This platform will have a tactile 3D interface, with touchable, draggable areas for People (friends, family, organisations), Things (photos, videos, messages, feeds, news, notes), Times (appointments, plans, weather) and Places (maps, galleries). It will seamlessly access and present this interactive content from the phone itself - representing you - from friends, and from third parties.
This interactive content will be findable by tags, geo-tags and timestamps - it's semantic data, not document text. You'll be able to pick a Person, then see their related Things, Times and Places; or pick a Thing, to see it's associated People, Times and Places. Stuff will also be findable by recommendation and trust, or at worst by well-targetted advertising.
Loss of Internet will be handled gracefully - stuff from others will still be visible, but simply not updated. There are no central servers, so loss of a server only affects the particular content it sources and 'animates' for you.
Third parties will easily be able to add functionality and interactive content such as map overlays, media, news feeds, etc.. They just expose them using the open protocol and notation - they won't have to ask anyone in order to do so. Some contributors can adapt the Facebook, Flickr, Twitter and various IM APIs in the same way. This will require a system for reconciling the multiple identities of users and their contacts.
There will need to be a virtual property system backed up by crypto keys and supporting payment - just because we don't have an App Store, doesn't mean we can't charge for interactive content! It will also be possible to charge for premium services, such as remote storage space for over-enthusiastic photo-snappers.
Blueprint for the Mobile 2.0 Killer Application
Right, we need to describe some more important things with capital letters, because we're going to talk about the best open notation and Internet protocol for sharing, mashing and updating...
We've already introduced People, Things, Times and Places. Call these Entities. Entities are open data - they have a current State. We'll use a text-based notation to describe their public State, because it's easy to read and write. Each Entity will conform to an open standard public schema or syntax.
Entities can Link up because they will each have a UID (unique identifier). Some friends-People met at the last-week-Time and the Tower-of-London-Place and took these photo-Things. I have a collection Thing of People and both personal and public collection Things of photo-Things. You get the idea. That's a form of mashing. Oh - photos on the Web can be wrapped in Entities that pull out their metadata, and Web URLs are valid Links.
Any Entity can Observe another. Well, it's mostly People Entities doing the Observing and being Observed, via the mobile device: my Person Observes your Person to see what you're up to, then Observes your collection Thing of latest photos and may watch you on the map Place as you head towards me snapping more. Sharing and updating.
But some Things can be Observers, too; the more interactive ones that are affected by Entities around them. A simple example may be a restaurant review summarising Thing, that Observes and averages the scores off several reviewers' submission Things. Each time a score is added or changed, the final score adjusts accordingly. That's sharing and updating, too, and Entities that depend on other Entities is another form of mashing.
Entities have read permissions, which control which People and other Entities can see their State. Crypto tech may be needed to support this in some cases. Entities don't have write permissions as such, because they control their own State as a result of what they Observe.
Of course, these Observations occur over the Internet. This will use an open standard publish-subscribe, peer-to-peer protocol. An Internet packet will subscribe to an Entity's Link, another packet will return current Entity State, subsequent packets will broadcast State updates to current subscribers. State is transferred into servers and handsets as required, by a combination of pull and push - sharing and updating. The protocol will ultimately also have to support things like streaming and real-time media; over Wifi at least, so as not to scare off the carriers...
The U-Web Mobile 2.0 platform
This Mobile 2.0 Killer Application for sharing, mashing and updating People, Things, Times and Places ... will have a shorter name! I'm calling it the 'U-Web' Mobile 2.0 platform at the moment, reflecting its affinity to the Universe Web I described before. The U-Web platform application will be free and the protocols and formats outlined above will be open.
The typical handset specification and APIs we're aiming for are: at least 320x320 touch screen with Embedded 3D; GPS, Wifi and good 3G; front- and back-facing cameras.
There's a large number of Windows Mobile devices that match this, including phones from HTC, Sony-Ericsson, Samsung, etc. There's currently one Symbian (the Nokia 5800/Tube with the N97 to come next year). One iPhone. One Android. One Blackberry without Wifi (the Storm).
Although Nokia's plans are somewhat unclear, their S60v5/Qt/Ovi offering looks like it may preclude the U-Web, especially since the U-Web wants to be the top app... The U-Web certainly wouldn't be allowed onto the Apple App Store - the clue is in the name! Writing it in C also rules out Java phones, such as Android - which in any case is another app-oriented platform - and any Blackberry handsets.
The U-Web should thus be written for Windows Mobile 6+ Professional handsets. At least their users will have a ready appetite for anything integrated and easy to use, that keeps them clear of the .. clumsy .. operating system. It will also be worth keeping an eye on the various Linux MID (Mobile Internet Device) platforms, including OpenMoko, Maemo and Moblin, and maybe LiMo. Similarly, we should write for Windows and Linux on the server side - the code will be essentially the same. It'll need to be written in C as the lowest common denominator, most efficient language.
The U-Web will be the top or idle application: on Windows Mobile it would replace the Today screen, or more likely TouchFLO 3D or Spb Mobile Shell. Else it could be an Xperia X1 Panel. Like these, it will give access to phone functions such as calls, texts, camera, speaker mute, Bluetooth and Wifi enable, lock screen, brightness, etc.
Of course, it won't actually be the only application while it is in its beta phase - people may still want to access a browser, email and various settings and utilities. The need for browser and email should reduce significantly when functions such as Web 2.0, messaging and file sharing are drawn up into the mobile-native U-Web, leaving just actual documents fitting awkwardly.
Opportunity
It is a mistake to see Mobile as just a second-class computing platform or as a miniature office desktop onto which you must squeeze applications and documents.
Mobile represents a whole different world of personal interaction and almost 100% presence - especially now that mobiles are becoming Internet-connected and location-aware and are being furnished with top-quality cameras and touch screens. The mobile device represents you, here, now; what you're seeing and doing, to your social network.
A Mobile 2.0 platform needs to drop closed applications and go instead with the flow of People, Things, Times and Places. It needs to transparently share, mash and update people and their stuff.
The U-Web Mobile 2.0 platform described here is designed to seamlessly merge your real and virtual lives, starting with intuitive, 3D touch interfaces that give an almost tangible feel to virtual property, then expanding out to touch the 3D lives of others.
If you take a photo, your friends can instantly 'join you on the map' where you stand and chat about it - and the weather conditions you're experiencing. No need to upload to photo sharing sites with logins, or to launch isolated chat, map and weather apps.
The opportunity is billion-scale - increasingly capable mobile devices will become the world's primary connected computing device, outstripping PCs and making current Internet and Web usage look like just a warm-up.
We should be in there with appropriate software when that happens. We can stumble into this step-by-painful-step via applications and browsers, or we can just let go and meet the actual requirements - with a platform for mashing dynamic, shared data.
I'd be delighted to hear from you if you're interested in helping or getting involved in any way with building this platform! Email me - link's on the left - or leave a comment.
Since the announcement by IBM and Linden Lab that OpenSim can talk to Second Life, I've been thinking again about RESTful Virtual Reality.
I'm not the first, of course. Others have been motivated by the same goal: To bring the Web's scalability, linkability and interoperability into Virtual World platforms.
Ultimately, how to use the same techniques as the Web to link Virtual Worlds together into a single, massive 'Virtual Universe'.
Here's how I would architect the Universe Web... ...
Since the announcement by IBM and Linden Lab that OpenSim can talk to Second Life, I've been thinking again about RESTful Virtual Reality.
I'm not the first, of course. Others have been motivated by the same goal: To bring the Web's scalability, linkability and interoperability into Virtual World platforms.
Ultimately, how to use the same techniques as the Web to link Virtual Worlds together into a single, massive 'Virtual Universe'.
Here's how I would architect the Universe Web...
Entities
The Universe Web needs Entities. (I'm going to be capitalising Significant Things a lot here to help the Web comparison - hope you don't mind). There's no need to make the Entity list too complicated since we're not doing online games yet - just a world like Second Life.
Here's a list of different kinds of Entity:
State, Links and animation
Entities aren't exactly the Objects of Object-Oriented programming: they have lots of public State. In a Virtual World, you can directly experience their colour, position, orientation, physical relation to each other, etc., thanks to the local render engine.
The basic structure of the Universe Web is made up of Linked Entities. A tree is Linked to its ground which is Linked to a building which is Linked to its occupants which are Linked to their clothing. Kneebones may even be Linked to thighbones.
Entities are often animated. Actually, Places are generally static, and People generally animate themselves. So, when talking in general, we should look at the animation of Things, like trees, books, birds and clocks.
There are two ways an Entity's animation can be guided: by Laws and by Rules.
Laws
Springiness is a handy Law. For example, tree branches, pages in a book and birds' wings and legs can all have springiness. We can declare a mid-air location in a bird's State and a springiness in its legs, then if the bird lands on a branch, the springiness can trigger the bird and branch waving gently to a halt.
We could even allow a single bird to become part of a flock Entity, where the flock only knows how many birds it has and the coordinates of its centre. Each bird will then be animated by global flock Laws.
The book can have a State of open or closed. If bookness was elevated to a global Law, then a book deciding that its State was now simply closed could trigger the elaborate, springy closing of its pages with a nice 'shlump' sound at the end.
The clock's current time may be set by the clock Entity itself, then the Law of time take over in between the clock updating its own time directly.
A Law can be invoked over an Entity's animation by simply adding the Law's name and parameters to its State. Such Laws can be handled by the physics engine in the same way surface texture is handled by the render engine: States such as 'red' need global meaning, Law applications such as 'springy' need global meaning.
Rules
When a clock reaches its alarm time, it rings. When its wizard master approaches, a magic book may glow and open. Birds fly away from danger (if a fox is too close, fly away from it). In between danger, birds and foxes look for food (if a bird is close, run towards it).
These are Rules. Rules are driven by the Observation of one Entity by another. The fox Observes the bird, the book Observes the wizard. Rules apply to Entity types: fox Rules, bird Rules, book Rules, etc. Rules can guide the animation of an Entity by evolving its State.
State evolution depends on the current State plus the States of the Observed Entities: Rules make an Entity change from one State to the next by taking the Entity's own State, Observing the States of the Entities around that it cares about, then deciding what the next, new State should be. If an Entity changes State, those Entities Observing it may themselves change State according to their own Rules, and so-on.
Links are part of an Entity's State, and Links may therefore change on the application of Rules. In other words, the virtual world may restructure when a Rule is run.
An Entity may either Observe another Entity, or Link to it, or both. An Entity that Links to another needn't Observe it. Trees don't bother to Observe the ground they grow from. Conversely, an Entity that Observes another needn't Link to it. A fox would only Link to a bird if she was lucky enough to catch it. Meanwhile, it is true that there's probably a chain of Links to everything that's Observed.
Unlike Laws, Rules can't or shouldn't be second-guessed, so have to be run 'at source' or 'inside the Entity', then the new State distributed to both the Observing Entities and to all the render engines.
But render engines are actually Observing People Entities..
People are First Class
In Virtual Worlds, we have People avatars: People are first class Entities. People can Observe and can change State, but it's a real user doing the animation, not a set of Rules. Observation and State change by a Person is implemented through the render engine.
Although self-animated, People can still make use of Laws. For example Laws can be invoked to allow gestures to be easier to make and to look better, and to allow People to 'run forward' rather than putting their 'left foot forward, ..'. Avatar skills become global Laws which can be triggered by an avatar's State animated by a user.
The Universe Wide Web
The Universe Web I've just described is a lot like the World Wide Web:
A crucial difference between the Resource Web and the Entity Web is that, here it's another Entity doing the Observation. One Entity transfers its State to another.
It's as if the GET or POST has another Entity 'at the client end'. GET is like an Entity subscribing or Observing; POST is like an Entity publishing or notifying its State to another (an HTML form has a content type, too).
People are just examples of that Entity 'at the client end'. Instead of a user hidden behind a client browser, we have first-class People Entities doing 'GET's and 'POST's: Observing the Virtual World and acting (i.e., changing State) within it. Other examples are foxes and clocks.
Notation and Protocol
There are two open standards we need to have in progress while implementing the Universe Web: the notation and the protocol (our HTML/URI and HTTP).
Firstly, we have to define the notation for Entities and their Rules. Both the State of Entities and the Rules that animate them will be written in the same notation: a Rule talks directly about State. To me, basing that on JSON (rather than XML) is a clear choice. Add inter-JSON Entity Links (essentially UUIDs), then work out a simple JSON Rule language. We will then need to define JSON 'schemas' for the kinds of Entity we would model. These can be written in the Rule language itself.
Secondly, to define the protocol for Entities to Observe or subscribe to one another. It will be a 'symmetric, asynchronous HTTP' - a Peer-to-Peer, Publish-Subscribe protocol. UDP and Multicast stand out for this kind of interaction. A packet will subscribe, a packet will return current State, a subsequent packet will multicast State updates. We can re-use all the HTTP cache headers, only now we can push updates into caches and into render programs. Packets will inevitably end up tunnelled through TCP and HTTP, mind...
This lighter notation, which also breaks the data up into smaller pieces, and this multicast pushing of State change into caches, along with P2P-style operation, will mean the Universe Web scales even better than its parent.
Also, programming declaratively using Rules is both highly productive and further cleanly scalable through parallel processing.
Of course, it will be pretty trivial to allow inter-Web cross-over such as referring to PNG texture images via URL and pulling Universe Web Entities into a Javascript application that subscribes to them via Comet.
Building the Universe Web
So that's my Universe Web. It's basically the same as the World Wide Web and thus as scalable, linkable and interoperable. It comes with added symmetry: Entities, including People as avatars, exchange State in each direction.
It's a two-way data Web, not a one-way document Web.
I've started work on the Universe Web: the notation, the protocol and the implementation (in C, for portability across platforms, including mobile). Contact me if you want to help!
Web 2.0's definition includes seeing the Web as an application platform. Which means it is in competition with Java and .Net, and with SOA, for both local and widely distributed applications.
If the Web is going to be a platform, the skills you need to learn to program it are the core Web 2.0 technologies such as Ajax, JSON, Atom, Microformats and OpenID.
And Ruby. This language, that's capturing the hearts of many Web 2.0 programmers, is ideal for easing the transition from the Java and .Net platforms to the Web platform, as I will show.
Even if you're part of a big company that is generally immune to the latest trends, the marriage of Ruby and the Web-as-platform may be something to prepare for. It could even displace your SOA agenda... ...
Web 2.0's definition includes seeing the Web as an application platform. Which means it is in competition with Java and .Net, and with SOA, for both local and widely distributed applications.
If the Web is going to be a platform, the skills you need to learn to program it are the core Web 2.0 technologies such as Ajax, JSON, Atom, Microformats and OpenID.
And Ruby. This language, that's capturing the hearts of many Web 2.0 programmers, is ideal for easing the transition from the Java and .Net platforms to the Web platform, as I will show.
Even if you're part of a big company that is generally immune to the latest trends, the marriage of Ruby and the Web-as-platform may be something to prepare for. It could even displace your SOA agenda...
Few would disagree that the Ruby language is riding the wave generated by Ruby-on-Rails. In turn, Rails is riding the Web 2.0 wave, coming as it does from underpinning the very Web 2.0 37signals product suite.
Rails and Ruby have tapped into the tech Zeitgeist of friendly, simple and powerful. The speed with which the Ruby and Rails communities have delivered the key components of Web 2.0 is matched by the speed at which Ruby and Rails books are leaving the shelves.
What is the ideal platform of Web 2.0? Will it be Rails and Ruby? Will Ruby ride the Web 2.0 wave into the mainstream in the same way Java rode the Web 1.0 wave?
Well, here's the problem with that question: Web 2.0 is supposed to be primarily about the Web itself as the platform, as explained first by Tim O'Reilly and then by a thousand Web 2.0 vendors and industry watchers after him.
Web-as-platform is not just vendor hype or pundit hand-waving. Let's think about what O'Reilly meant by that.
Web as Platform
Web 2.0 is about making the Web more interactive, and thus able to support applications where Java and .Net would once have been considered the sole delivery platforms.
The fact that the technologies of the Web can be turned to this use is a shift with far-reaching implications.
Broadly, the shift we are seeing is from the one-way, static document delivery of Web 1.0 towards the two-way, dynamic data exchange of Web 2.0.
This fundamental repurposing is delivering more complex, interactive applications that work inside our browsers and which fully leverage the benefits of online operation.
Web 2.0 is bringing the user and their stuff into the very Web that they hitherto only passively consumed. This network-enablement of the user in turn enables their social networking and their shared creativity and self-expression.
Web 2.0 has tapped into a deep human need - a fact reflected in the vast traffic volumes and correspondingly vast valuations of Web 2.0 startups that we're currently seeing.
But Web 2.0 is not just for the startups: Enterprise Web 2.0 is coming! The bigco.com site is going to be looking a little, well, static and lifeless when compared to the new sites that are springing up everywhere, and that most of BigCo's employees are using. Further, BigCo can gain huge benefits from Web 2.0 approaches empowering and connecting those employees on the Intranet. And that Intranet is an ideal platform for deploying company-wide, interactive applications.
This shift in the Web to two-way dynamic data is being powered by a set of technologies that a Web platform programmer is going to have to learn.
Web 2.0 Platform Technologies
Anything that claims to be an application platform must support data. Web 2.0 is above all the data Web. Web 2.0 is about semantics, not free text and font sizes. Hence, it inevitably starts with data-oriented formats such as XHTML, YAML and JSON. In Web 2.0 more than ever, we talk about data not documents and about separating data from its presentation. CSS is big in Web 2.0, for good reason (not just for gradient fills). Inside the page of a self-respecting Web 2.0 application, you'll often find Microformats - again, semantics in the page: publishing concise data of widely-understood standard formats. Some of those Microformats may be tags, and in Web 2.0 the simplest and most powerful semantics are those little pivot points in Webspace.
Again, if you're going to be a general purpose platform, you need to be able to fetch, update, notify and display that data. Web 2.0 integration usually happens via JSON data structures and REST interfaces (some of which, especially those based on AtomPub, are true REST). Following on from the data-like pages we serve to browsers, come the data-like feeds we publish to feed readers and to other applications. After feeds, the core technology that gives Web 2.0 its dynamism and interactivity is Ajax and DHTML, and increasingly Comet (server push to the browser). The core technology that gives Web 2.0 its users is increasingly OpenID.
All of the above are open technologies. You can do Web 2.0 without proprietary technologies, just like Web 1.0. Indeed, keeping to the principles that made the Web successful is also essential to the success of Web 2.0. The Web platform is the first application platform that has to consider scalability and interoperability, and will ignore them at its cost. I have written before about open data, use of standard data formats and using REST properly to avoid creating unscalable, walled-garden sites. You don't need Flash or SilverLight, you don't need vast amounts of custom Javascript, you don't need function calls tying you to your servers.
Programming the Web 2.0 Platform
So, we've got the dynamic data that you'd expect of a would-be platform. But how to drive changes in those data? How do we program the Web platform to animate all this data?
All Rails programmers will know the above technology list; it comes with the territory. The Web 2.0 Platform can be very succesfully powered by Rails and Ruby. Ruby and Rails make Web 2.0 applications simple and quick to program, addressing many of the needs of simple Web 2.0 applications out of the box. There's little doubt that Ruby and Rails will have a secure future riding the Web 2.0 wave.
However, for many Web 2.0 applications, programming may not even be necessary, at least not in the procedural or imperative style programmers expect.
Look back to the early 90's: 'Web 1.0' made a whole class of applications easy to write without programming: applications for navigating information. You just wrote in HTML, declaratively.
Now look back at the long path of evolution of Java, through J2EE, Spring, AOP, IoC, Domain Driven Design, POJOs. All trying to achieve the simple goal of 'remove all that MVC and persistence stuff and let us concentrate on business or domain objects'. But they never quite seemed to get it right.
But then Rails comes along, and has succeeded by simple virtue of concentrating on easy manipulation of the 'Intel Inside' of Web 2.0 - data.
It's reminiscent of the 'Naked Objects' approach to application building with minimal programming (just business or domain code in POJOs that expose state into the GUI and are transparently persisted). The Streamlined project takes Rails even further down this path. Rails' nearest competitor, Django, has an admin interface that works in a similar way, automatically generating edit pages based on the data model.
Web 2.0 is about data, about semantics. Web 2.0 is inherently declarative. So Web 2.0 applications can be written declaratively - Web 2.0 mashups can be just wired together and their data animated by business rules. A bit like programming spreadsheets.
Teqlo, Coghead, Pipes, DabbleDB, LongJump, Popfly, AppExchange and Wyaworks are all examples of the different ways to program the new Web 2.0 platform without imperative code.
That's what we mean by Web-as-platform - not only is the underlying programming language irrelevant, it will often not even be needed, certainly for simple data manipulation applications and for many simple mashups. Being RESTful gives you a massive head start in this, of course.
While Rails is already in the game with its innate understanding of Web 2.0 techniques and philosophies, Ruby itself has a huge amount to offer the would-be declarative programmer, who is making the transition to this new Web platform from their traditional Java or .Net platform. In particular, it is easy to write your domain logic in a declarative style in Ruby: they call them 'DSLs' these days, but the idea is the same in most examples I've seen.
Web 2.0 - The Web Redux
Now, if you've been following this blog, you'll know I have a few opinions on Declarative Web 2.0 and on patterns for programming REST. Essentially I argue that, if you want to play in the Web 2.0 platform game, you don't want to be writing screeds of Javascript functions that call more functions on your servers.
I recently presented some ideas along these lines at the WWW2007 conference, entitled 'The Micro Web: putting the Web back into Web 2.0', where I also showed a demo written in Python.
This approach combines my Distributed Observer Pattern with Comet push to enable highly dynamic Web 2.0 applications to be coded RESTfully and declaratively, with zero Javascript. The Distributed Observer Pattern offers a clean programming model for animating the Web 2.0 dynamic-data technology set I described above.
I believe the Observer Pattern is core to the way we'll be programming when the Web 2.0 Platform hits mainstream. It enables the kind of event- and rule-driven programming that matches the characteristics of the Web 2.0 dynamic data platform. As a further killer benefit, it also directly addresses the optimal utilisation of multicore processors.
I am currently porting my Python implementation of this approach to Ruby, in the Redux project on Rubyforge. Redux stands for 'Ruby Event-Driven Update Exchange'. It uses the highly scalable EventMachine epoll-based event loop to power its event-driven architecture. This will be essential when Redux is asked to scale up a Comet-based application.
Like Rails, Redux will be a Web (2.0) application framework, but unlike Rails, it puts the Observer Pattern and event- and rule-driven programming at its core.
Redux's headline is 'Web 2.0 in-a-box' or 'Naked Objects on the Web'.
Conclusion
If you're in BigCo, and are responsible for setting BigCo's technical strategy, then train your Java devs up on Web 2.0 core technologies such as Ajax, JSON, Atom, Microformats and OpenID.
And fire up their enthusiasm by tapping into Ruby (perhaps via JRuby) on your way to the Web 2.0 platform.
Learn patterns for mashing and integrating. Learn about REST and event- and rule-driven programming, including declarative DSLs.
When this Web platform hits BigCo, you will probably find that its REST or ROA style make your SOA integration strategy look rather complex and unweildy.
Check out the Distributed Observer Pattern, and download Redux when it's done (I'll let you know if you subscribe here!).
In 2007 and beyond, its the Web itself that's the platform, not Java or .Net. But if you want to get there via a language-based platform, Ruby could be the best way to transition to it.
Note: Everything I said about Ruby and Rails applies equally in technical terms to Python and Django, but regardless of the significant benefits of the latter, Ruby and Rails have the Web 2.0 market and mindshare. I'll probably switch this blog from Django to Redux sometime this year..
(c) 2007 Duncan Cragg
Open Data .. has .. recently .. been.. all .. over .. the .. blog .. o .. sphere!
Openness is a classic Us-and-Them issue. Big, nasty Apple/MySpace/Flickr is trying to control what little me/SingleStatus/Zoomr can do with my/our own stuff.
Open Data vs. Closed; Open Source vs. Proprietary; P2P vs. DRM; privacy vs. surveillance. The battles between the freedom of the pioneer, the individual and the minority against the rules and stability of the establishment and the majority form the endless shape of human history.
Us beating Them is Hollywood's favourite subject on-screen - and ironically Them fighting Us Hollywood's favourite battle off-screen.
As an Us-and-Them issue, with Us less powerful than Them, it's also tempting to give up and to follow the crowd - to do what we're told, to not ask for or sieze the privacy and open data we feel entitled to.
However, at XTech 2006 recently, there was a set of talks on the subject with a more positive approach. ...
Open Data .. has .. recently .. been.. all .. over .. the .. blog .. o .. sphere!
Openness is a classic Us-and-Them issue. Big, nasty Apple/MySpace/Flickr is trying to control what little me/SingleStatus/Zoomr can do with my/our own stuff.
Open Data vs. Closed; Open Source vs. Proprietary; P2P vs. DRM; privacy vs. surveillance. The battles between the freedom of the pioneer, the individual and the minority against the rules and stability of the establishment and the majority form the endless shape of human history.
Us beating Them is Hollywood's favourite subject on-screen - and ironically Them fighting Us Hollywood's favourite battle off-screen.
As an Us-and-Them issue, with Us less powerful than Them, it's also tempting to give up and to follow the crowd - to do what we're told, to not ask for or sieze the privacy and open data we feel entitled to.
However, at XTech 2006 recently, there was a set of talks on the subject with a more positive approach.
I'm counted amongst the 'founding members' of the UK's Open Rights Group, having signed the pledge in PledgeBank. So I was delighted to see Suw Charman's name on the XTech programme.
Suw gave a talk about the issues they/we are tackling: ISPs and Telcos tracking our traffic, DRM controlling our media and even our computers, ID cards, Patents, various government schemes to undermine our privacy, Copyright extension, Trusted Computing, etc., etc.
Read about the issues, then join the group (or the EFF, etc., depending on where you live).
Now, this was cool. I'll start right off by noting that they have a REST API, not a STREST API..
And it just gets better from there.. OpenStreetMap is like a Geo Wiki of GPS trails around the world. The centre of London was mapped by attaching GPS devices to couriers and plotting the slug-trails they left behind. Steve Coast showed an animation of a day's tracking. The trails shot off to various points out of town at the end of the day. But the animation continued..
And at pub closing time, another burst of trails as the couriers came home!
A few weeks ago, a crowd of OpenStreetMap volunteers descended on the Isle of Wight in England to walk around mapping it. The enthusiasm generated by this project seems likely to give it enough momentum that it will very soon be good enough for us to use for real. A complete, reliable dataset created by the people, for the people, unencumbered by copyright and restrictive licensing.
I suggested an idea I had about five years ago in my dot-com days: let people upload mobile-snapped pictures with GPS coordinates attached. Central servers scan the pictures for text and OCR them into a searchable database.
People would snap-and-upload their own street name signs, house name plaques, shop fronts, station name signs, company office signs, etc. Even menus in the local restaurant. We could construct a 'GeoGoogle' of public, mappable, searchable text.
However, Steve told me that OCR and mobile GPS technology still isn't up to it; that manual tagging of GPS trails is enough to make OpenStreetMap work well. Ah well, I've waited five years, so I can wait a bit longer...
Paul Hammond (ex-BBC, Yahoo!) gave a good talk on how to motivate companies to open up their data to the Mashable Data Web, hopefully through nice shiny new Web 2.0 APIs.
Here's your takeaway quote courtesy of Suw Charman's amazing typing:
- Be aware of the problems
- Demonstrate usefulness, screen scrape if you need to, but don't get yourself cease-and-desisted
- Don't assume it's a technology problem
- Target the right people, find someone on the inside who can help you
- Talk about benefits to the provider, not the consumer. If you talk about the benefits to you, they'll see you just as someone who wants something for free.
- Have patience. It is getting better every day, and it takes time for business to come round.
The Data Web will be created mostly from the edges, but the middle should be encouraged to see the benefits, too.
Native to a Web of Data: Designing a Part of the Aggregate Web
Yahoo! had a big presence at XTech - as did the BBC - and this Yahoo! - and ex-BBC - presenter was Tom Coates.
Tom's talk extended the previous one of his colleague, Paul Hammond, by going over some principles of opening data and helping build the Data Web.
Principles such as finding data sources, giving them nice representations and URLs then distributing them in a most accessible and navigable way.
A bit Web 1.0, in truth; he looked rather blankly at me when I suggested adding some concept of data events or updates to his list of data-opening principles.
Again, Suw has this written up (actually, a better-looking version of the same talk from FoWA).
Oh - here's a good article by Tom on the power of pointability
Harnessing the Collective
All of these talks had a positive spin on the Us-and-Them issue.
We can do something about the creeping imbalance of Digital Rights, tipping slowly but persistently from Us to Them.
Web 2.0 and the Social Software it underpins can actually empower those of us that are willing to use it.
As taxpayers, voters, shareholders, pensionholders, customers and employees, we really do own and control Them. We are just one Social Networking movement away from realising that - in both senses of the word.
So: stop staring at YouTube, sign up to your local Digital Rights organisation, get out on your bike with your GPS, understand and talk nicely to that unenlightened, data hoarding corporation and start a bottom-up revolution to take back control over your own data...
Above all, design your systems to put Open Data at the top of your list of priorities...
Declarative Architectures focus on the What, not the How, of programming. The How has dominated the field - perhaps 80% of programming is done in the traditional Imperative style, where we tell the computer How to do a task in explicit steps.
I'd like to show in this blog how Declarative Architectures and technologies are not just an interesting sideshow to the main Imperative attraction, but a complete and powerful programming alternative in their own right - indeed, one which has already dominated certain fields.
Imagine being able to simply express What we want the computer to do - to give it constraints and rules - then let it work out for itself How to achieve our goals.
I believe that saying What, not How, will become the dominant paradigm in programming. ...
Declarative Architectures focus on the What, not the How, of programming. The How has dominated the field - perhaps 80% of programming is done in the traditional Imperative style, where we tell the computer How to do a task in explicit steps.
I'd like to show in this blog how Declarative Architectures and technologies are not just an interesting sideshow to the main Imperative attraction, but a complete and powerful programming alternative in their own right - indeed, one which has already dominated certain fields.
Imagine being able to simply express What we want the computer to do - to give it constraints and rules - then let it work out for itself How to achieve our goals.
I believe that saying What, not How, will become the dominant paradigm in programming.
What?
Declarative Architectures are about data: documents, assertions, truths, rules, tables, structures, state, bits. Data storage, changes, constraints, transformation, sharing, querying, fetching, interaction, presentation, subscription, tagging.
In summary, we talk about stuff, changes to stuff and rules governing stuff. Not processes, actions, jobs or functions.
It's amazing how many interesting Declarative technologies are actually out there already - especially given that most programming is Imperative. They tend to go unnoticed; subservient to their Imperative masters.
Here are some examples from our daily work life (assuming you work in computing!):
What all these have in common is that they are purely data- and event-driven or oriented. Not a thread in sight (if used properly). No method calls. Just querying, fetching, subscribing, tagging, declaring truths and rules, making changes to stuff, etc.
On the 'Net, all the dominant technologies are actually Declarative, not Imperative:
Again, the same things are happening: querying, fetching, subscribing, tagging, declaring truths and rules, making changes to stuff.
Email (SMTP) is a great example of a Declarative Architecture, with its routing and transformation rules and self-addressed store-and-forward transmission. And, in fact, much the same applies to the rest of this list, where the Declarative aspects may include network querying and data events.
Imperative protocols such as RPC, RMI, CORBA, SOAP, etc. haven't had anywhere near the impact of their Declarative cousins.
Now, consider the 'Web 2.0' technologies:
This is a wonderful list of Declarative approaches (as long as we use REST APIs and talk about Resources, not SOAP ones talking about functions and jobs!).
So far, I've mentioned technologies that have attached themselves to the periphery of Imperative programming, where the actual behaviour is still driven procedurally, or How-like.
However, Declarative programming itself has a history at least as long as Imperative programming, and includes:
We can, if we choose, write 100% Declarative systems (even down to asynchronous or event-driven operating systems and hardware).
Wherefore?
In this blog, I'll be pointing out opportunities where we can benefit from the Declarative approach when it's ready.
Perhaps the biggest example of a Declarative Architecture that is ready to benefit us now is the Web. In contrast, the Imperative Service-Oriented Architecture model and so-called 'Web' Services are still weaning; still trying to get a life free of their huge standards consortia. REST, in its simplicity, ubiquity and straightforward usefulness is orders of magnitude more deployed than SOAP will likely ever be.
This blog is for discussing the common problems and solutions in Declarative technologies; seeing if ideas in one area can be used in another and seeing if we can distill their lessons and their approaches.
Ultimately, heading towards a unified, distributed Declarative programming technology landscape.
I hope you'll join me in my explorations into Declarative Architectures, in particular if you're interested in the currently most promising segment I mentioned: Web 2.0, and its application in Social Software.
Or the currently massive but little-mentioned segment: Peer-to-Peer, and its application to the disruption of, well you know, all those big technological and commercial hierarchies...