Microsoft Mesh

Details of Microsoft Mesh are finally emerging through the fog of Microsoft's PR department, and I think it's going to be absolutely massive. They've found a way to extend their C: drive monopoly to the web.

Basically, Mesh will turn your PC into an Atom Store, publishing your C: drive to the internet as a set of feeds. You can publish any local Word Documents, images, videos, or even folders.

What's more, your C: drive will obey the Atom Publishing Protocol, meaning other services will be able to post, edit or delete local files. This will be used to synchronise your local content with an online space, presumably a version of Sharepoint with developer APIs. Of course, this will turn every PC into a web server - I suspect the only connections allowed will be to Microsoft's servers.

This is exactly the kind of service I had in mind here!

Microsoft have finally found a way to extend their dominance of the PC to the web - via the C: drive. Now, your pictures in "My Pictures" will be automatically synched with Microsoft Live Photos whenever you turn your PC on. Why would you ever then manually upload them to Flickr? And your Office documents will be automatically synched with a personal Sharepoint that presumably enables document sharing. What's the point now of Google Apps?

Mesh finally makes the slogan "software plus services" meaningful. And they do it by using web standards - HTTP, ATOM and URLs. However, the remaining web standards - HTML, CSS and Javascript - are still being avoided on the client, in favour of binary files like Office documents. That will make it difficult to synch HTML documents created on the web (e.g. lists, and tables) back to the client.

This is definitely a half-way house. The only reason synchronisation is such an issue is that we're still storing data locally on clients, rather than in the cloud. But 50% web technology is much better than 0%, which is what Microsoft provide at the moment. Mesh will protect their Office monopoly for a few more years, but it will still surely crumble eventually in the face of HTML5 and CSS3. Microsoft are betting that Mesh will carry them over until they develop more competitive web applications.

Of course, if you have an Apple iPhone or Mac, or indeed use Linux, you will not synch with Microsoft. You will also have no need to synch with Microsoft if you already rely on full web technology, such as Google Apps. But if they can execute, Microsoft will once more be a force in Silicon Valley.

Web Communication

Technology is there to enable people to do things. So, if you want to write a successful application, it's worth asking what things people like to do! And there's one answer that has proved itself time and time again - people like to communicate.

The killer apps of the internet have always been communication tools - starting with email, moving to webmail, instant messaging, blogging, Twitter streaming, and most recently social networking.

So how far has the web come in enabling communications? I put chart together to work this out.

Communication types

Timing	View	Add	Method
Asynchronous	Private	Private	Notebook
Asynchronous	Private	Public	Email / Voicemail
Asynchronous	Public	Private	Blog
Asynchronous	Public	Public	Wiki
Realtime	Private	Private	Dictaphone, CCTV
Realtime	Private	Public	Instant Message
Realtime	Public	Private	Twitter / TV / Radio / Webcam
Realtime	Public	Public	Phone / video conference

The most obvious thing to note is that every cell in the table has something in it, so there are no obvious gaps - but many are filled with very recent technology, and it's still changing very quickly.

Secondly, the table drives home just how important and useful the Atom Publishing Protocol is - starting from blogging, it is spreading to all the asynchronous types of communication. That shows some foresight from Google, who have based their architecture around the standard.

Thirdly, realtime communications technology seems less mature. That's not a surprise - HTTP was designed for the asynchronous request / response pattern. So it will be interesting to see how this piece develops.

Ajax and the iPhone: great, but what about RSS?

So, Apple announced that the iPhone will be programmable, but only using HTML, CSS and Javascript.

Most people were pretty underwhelmed by this news - it sounds like Apple's quick fix to build a development community, and it probably is.

But this is a massive story. We will finally have a popular device whose developers will have to rely entirely on internet standards. The internet will receive another boost, as developers realise how much they can achieve - even Google Spreadsheets - and, after the kicking and screaming has subsided, I don't believe they'll want to look back to proprietary client technology.

After all, the desktop world is moving away from client applications towards the internet - and it's going to be the same on the smart phone.

Internet Apps, not Client Apps

Steve Jobs mentioned making a call and sending an email via Safari - I assume this means they'll support <a href="mailto:x@y.com">Email me</a> and <a href="callto:+112345">Call me</a> via HTML. At once, seamless integration with CRM and corporate directories will be straightforward.

Of course, this makes the decision to stick with GPRS, rather than 3G, even more strange. Download speeds will be pitiful once you're outside a Wifi connection. Surely they'll produce a 3G model soon, especially for Europe?

Offline RSS

I'd love to see offline RSS in the iPhone. If it synched your RSS feeds every time you hit a Wifi zone, and stored them locally for offline access, that would be a tremendous win.

After all, what is iTunes.com but a personalized RSS feed of music and video files? If your phone wirelessly synched up with iTunes.com, you wouldn't need to touch your PC!

And offline RSS would also allow me to synchronize with corporate files, Google's Picasa, news, and much more.

If that's not a good programming API, I don't know what is!

Emails, blogs, or wikis - it's just permissions

The only difference between emails, blogs, wikis, and notebooks is permissions.

See the table below, which lists the document type, view permissions, and add permissions.

View	Add	Document
private	private	notebook
private	public	email
public	private	blog
public	public	wiki

Other than that, they can use exactly the same technology (RSS / Atom), and exactly the same authoring WYSIWYG methods.

Currently, they're all separate tools - I can't see that continuing. We're likely to see integrated online authoring suites to handle all of them together.

Google Mobile Phone

Current rumours suggest Google is preparing a mobile phone. But I would be very surprised if Google got involved in designing hardware - it's not their core competency. Instead, I think the focus will be on a phone communications suite that revolutionizes the way we manage our inboxes, contacts, and calendars.

After all, the excitement surrounding the iPhone proves that people are looking for a better way to manage their personal communications. Blackberries are too corporate and clunky, phone address books are lost when you get a new phone, PC synchronization is a pain, and emails, voicemails, and text messages are all handled in different ways.

So it's worth asking what a mobile phone communications suite, done properly, would include:

• A unified inbox - email, phone / voicemail, IM, text messages - that synchronizes with Gmail
• A unified contacts database / phone address book, incorporating presence information, that synchronizes with Gmail contacts
• A calendar application, incorporating alerts, that synchronizes with Google Calendar

All of this could be achieved using just the phone's web browser, local HTML pages, and synchronization software to transfer data between the phone and Google.

In fact, most of the synchronization software already exists - GData, Google's Atom store of calendar and contacts information. All that's required is an application on the phone to acccess it.

By implementing these ideas, Google would be playing to their strengths - they understand the internet, and this approach brings the basic internet tools of the URL, HTTP, HTML, CSS, and Javascript to the mobile phone.

Immediately, Google would lock in new customers to Gmail and Google Calendar. And one day, I'm sure you will see Google adverts alongside your phone's address book

Personally, I'm excited by this vision. I long for the day where I can access my personal data from any device, especially one as handy as the phone. Let's hope Google follow their instincts and bring the internet to the mobile phone.

Connecting Digital Devices

The biggest problem in the consumer electronics industry is reportedly how to get devices to work together.

Everyone wants to sell the 'central device' that coordinates all others in the house, but no one can agree on what it will be - the PC, the set-top box, the games console, or even a new 'home server'.

What's more, no one can agree on what it will do - centrally store your photos, music and video, allow appropriate access to iPods and other computers, administer fridges, ovens and other objects, or just enable content to be shared across devices.

None of these ideas sound particularly enticing to me. Why would I want a complicated machine that manages all others in my house - can't they manage themselves? So long as I can listen to the same music on my iPod and stereo, or use the same address book on my phone and my PC, then I'm ok. If I really wanted to turn my oven on remotely, I would want to do it via any device - phone, PC, console - not just the central one.

What’s needed is not a central device, but a way for each device to publish content and services for the others to consume.

The solution is maddeningly obvious! We already have the technology - it's the humble URL! Why not give each device a URL, and why shouldn't each device publish its content to the web, for example via RSS feeds?

For example, my phone should offer its address book, call history, photos, and music via authenticated RSS (or Atom) feeds. And my PC should be subscribed to this RSS feed, keeping it automatically synchronized.

The beauty of this model is that it’s straightforward – people are used to typing URLs, and there are plenty of browsers around to enable it.

And it’s flexible. For example, rather than installing a web server on your phone, Google or Yahoo or Vodafone could host its content for you, by asking you to download synchronization software onto your phone. Then, you could see your phone’s photos and address book in Gmail or Yahoo! Mail. And from there, you could access them from any other device.

It’s also manageable. My web hosting company manages data backups, rather than me fiddling around on a PC or set-top box. If a device breaks or gets stolen, then I still have the data and I can turn services off, or delete content, remotely. If my train goes under a tunnel, then I use the latest RSS data cache for my email, rather than a live link.

Of course, subscription can work both ways. My phone could also be subscribed to my Gmail contacts RSS feed, so rather than fiddling around with phone keypads I could type my address book in Gmail, and it would synchronize automatically. Either Microsoft’s SSE extensions to RSS, or the Atom Publishing Protocol, could handle this.

I don’t think the power of the URL has sunk in, especially in the consumer electronics industry. The REST approach should be drilled in to product designers, and in particular the use of RSS / Atom for subscriptions and synchronization.

The whole problem of connecting digital devices boils down to publishing and syndication, and the solution to this problem is to use the internet.

Ajax is the beginning of the end for relational databases

On the web, every page is a text document. The text documents are interpreted and displayed by browsers according to a standard contract – HTML.

The classic client-server programming model works very differently – a Visual Basic application, for example, will contain all manner of binary files and libraries that directly call operating system functions. It’s like writing a new browser for each website!

The choice of model has far-reaching consequences – for example in security, in user interface design, in software distribution, and in application integration. But, surprisingly, one part of the classic model remains – the relational database. Mixing a relational database with online text documents should really not work:

• Database tables are not documents, so they can’t be referenced by URLs or appear in hyperlinks in a standard way
• There is no standard file format for database tables, so they can’t be transported in a standard way across HTTP
• Cacheing models for databases and web servers are inconsistent
• Relational database best practice is for data normalization, whereas HTML documents are naturally un-normalized and hierarchical
• Security works differently in the database layer to the web server layer, leading to potential inconsistencies and gaps
• Systems integration for databases is much more difficult, due to the lack of a common extensible approach to table structures and their transformations

As a workaround, developers borrow old client-server tools like ADO.net and JDBC links in object-oriented code, and mismatch them with the text document. This creates a complicated intermediate layer and doesn’t really address the issues above.

Since the biggest use of relational databases nowadays is to supply HTML documents, their massive take-up is something of a mystery. It’s explained by three factors – they are fast, they are stable, and they haven’t had much competition!

But now some competition is arriving at the low end – Ajax. Ajax offers the ability to look up reference data sources during runtime, which is exactly the function of a relational database. And by using URLs, HTTP, XML and javascript, Ajax overcomes each of the relational database flaws above.

Viewing Ajax as a competitor to a relational database might be unconventional, but it’s revealing. In Ajax, the XML file itself represents the database table. There is less focus on a query language like SQL - DOM javascript carries out the bare minimum, with XSLT transformations filling some gaps – but a lot more focus on getting access to the data via URLs and HTTP and XmlHttpRequest.

Apart from data access, the key advantage of Ajax is that it returns data in the same text document format as HTML. So it can be readily inserted without any intermediate layer – in fact sometimes with pretty much no code, using something like < div src="database.xml" >

Of course, you would never use Ajax to download an XML file with a million rows. But you could do some pre-processing on the server, and return a brief XML results file via Ajax. And this pre-processing step is becoming one of the main functions of relational databases – they are being relegated to storing data and returning query results in XML via HTTP, which his not their natural position.

Recently several groups have extended this approach. On the W3C side, an ambitious attempt to replace lines of javascript code with declarative XML binding has been defined – XForms. Although of great theoretical benefit, XForms is hampered by its lack of adoption by the browser manufacturers. And as a grassroots movement, the Atom Publishing Protocol is seeking to standardize the structure of XML databases. It does not require any browser enhancements and has already attained significant adoption, most notably by Google as the foundation for Gmail, Google Calendar and Google Docs & Spreadsheets.

My contrarian prediction for 2007 is that Ajax will take over from ADO.net and JDBC as the middle ground between web pages and data sources. The Atom Publishing Protocol will become a popular way to manage data sources – taking over even more of the relational database scope.

Relational databases will get decoupled from web application development. They will be increasingly relegated to XML storage and output, plus their traditional role in the declining client-server world. After more than 20 years, this is the start of their demise as the all-conquering database technology.

New uses for RSS / Atom

RSS, like its web standard sister Atom, was designed to support syndication across blogs. By opening up the data behind a set of blog entries, information could easily be shared across the internet without manual copy-paste or messy screen scraping.

Due to the massive growth and enthusiasm for blogs, all manner of technology to support RSS / Atom is now commonly available - downloadable client news readers, website based news readers, blogging sites, browser toolbars, even integration with the Vista operating system.

But like all great technology, RSS / Atom is useful for a lot more than initially realised. In fact, it's becoming one of the foundations of the web. Here are some examples:

• Business Process alerting engines: use a feed reader to monitor queues and automatically escalate exceptions via email, IM, SMS or VOIP.
• Document Management: replacing user-generated content in Windows Explorer and other document management systems with a set of RSS / Atom feeds. This allow for syndication, tagging, search, subscription, separation of presentation from content, and integration with internet technologies like CSS, HTML, the URI, and javascript.
• Synchronization: Using RSS / Atom to manage automated synchronization, for example between Blackberry / iPod and a PC, or between a PC and internet sites
• Email / Calendar / Contact storage: using simple extensions to RSS / Atom, it's possible to store emails, calendar entries and contact information as a native XML feed. This can replace the dreaded .pst file, bringing the same advantages as Office XML formats did over the old binary files.

The common theme is that RSS / Atom is an internet-based approach to managing sets - whether sets of files, of emails, or of blog entries, it handles them all.

Several extensions to RSS / Atom are in active development (as extensions, these work best with Atom which is namespace aware): Atom Publishing Protocol, to handle updates / deletes as well as simple views of data; SSE, to handle synchronization between feeds; and Gdata, to allow for native email / calendar / contact storage.

But even without these extensions, it's clear that over the next few years, RSS / Atom will become one of the most important foundations of the web.