One example: XMPP (a.k.a. Jabber) is the future for cloud services

Both of these shows cover the interaction of technology and the Internet with society in general. Topics range from intelligent and interesting discussion of the forthcoming Canadian copyright changes to the funeral of a main frame computer, and more recently the applicability of the publication ban laws in the presence of blogs and social networks sites such as Facebook.

What is really unique about Search Engine and Spark though is how far they go to integrate the show into the web; or maybe it’s the other way around. Both shows make extensive use of their websites for listener feedback and to look for new story ideas. If this doesn’t seem particularly novel take note of how much these shows try to integrate ‘blog culture’. Search Engine starts each episode with keywords like a blog post. All of the music used on Spark is Creative Commons licensed and linked from the show’s website. Most importantly both shows sound very personal. Almost like an audio version of a blog post at times.

On a final note, these are not geek shows. If you read blogs or publish your own or use Facebook regularly you are likely to get something out of each episode.

Here are a few interesting links.

Thoughts on the Social Graph
Social Network Fatigue and the Missing Web 2.0 Address Book
Opening up the Social Network Graph
Using Open Standards to Free the Social Graph

After you are done playing with the above take a look at the SVG video demo. It is basically the same demo as above but has movies playing instead of static pictures. Unless you run a development version of Firefox you’ll just have to watch the videos.

The Jabber/XMPP network forms an XML based overlay network. Each message or packet of information carried by this overlay network is an XML stanza. You can think of Jabber servers as being XML routers and the clients as end nodes. In fact, the instant messaging portions of the XMPP standards are defined in a separate RFC from the core XML streaming technology (RFC 3920, RFC 3921).

One example of a non-IM use of Jabber is defined in JEP-0072: SOAP over XMPP. This document specifies how SOAP, which is normally used with HTTP to form web services, can be carried on top of Jabber/XMPP.

Another interesting non-IM use of Jabber comes from JEP-0060: Publish-Subscribe (aka pubsub). Pubsub is basically an event notification system that runs on top of Jabber/XMPP. In pubsub, a user publishes some XML data to a Jabber server which supports JEP-0060. Other users are then able to “subscribe” to this node. Whenever the node changes, a notification will be sent to all subscribed users.

There are lots of interesting things that could be done with pubsub. Off hand, here are a few of examples:

• You want to checkout a book from the local Library. Unfortunately, someone else already has the book. In order to find out when the book has been returned, you subscribe to the node that represents that book on the library’s pubsub server. Once the book is returned you will know instantly.
• You plan on purchasing a large, expensive TV in the near future. Rather than manually looking at the websites for several major retailers every few days, you subscribe to the pubsub node at each retailer for the particular TV model you are interested in. If any of the retailers have a sale, you find out instantly.
• If like many people you use a RSS reader to keep up with new posts on your favourite blogs, you know that RSS readers periodically poll all feeds on your list. Often there are no new posts and this polling is a waste of resources. Instead, a pubsub enabled blog could notify interested readers of a new post. Not only do you find out about the new post sooner, network resources are saved.

In all of the above examples, subscribing to the particular pubsub node could be as simple as clicking on a link (JEP-0147: XMPP URI Scheme Query Components).

Also interesting is JEP-0163: Personal Eventing Protocol which defines a subset of the full pubsub (JEP-0060) specification which can be used for simpler instant messaging related tasks such as providing current geographic location information (JEP-0080: User Geolocation) or providing contacts with information about the music you are currently listening too (JEP-0118: User Tune).

It will be interesting to see how pubsub will be integrated into other network applications such as RSS readers and Jabber IM clients. It seems likely that pubsub notifications will be handled either by a Jabber client separate from the one that is used for IM or at least the Jabber IM client will have to distinguish these events from normal IM traffic.

For a nice overview of pubsub (with pretty pictures) see Jive Software: All About Pubsub.

Unfortunately, what is convenient for humans is not so good for search engines. There are two aspects of the standard blog format which cause search engine problems. The first is the dynamic nature of some blog URLs. Consider the main page of an active blog. Most only show about ten posts; older posts are removed as newer ones are created. Often this results in a particular URL not containing the content the search engine thinks it does. Personally, I find this incredibly annoying since I often have to search the site using a local search engine after Google has directed me to the main page of a blog. The second problem of the blog format with respect to search engines is that some URLs, like a category URL, contain many posts which are not directly related to a particular search. This results in having to search the page with the browser’s find function after the search engine gets you there.

Both of these problems have been annoying me for some time now. So today I did a little digging. Fortunately there is a solution, the robots meta tag. This tag specifies, on a page by page basis, whether or not the content on the current page should be indexed by the search engine and if links on the current page should be followed.

The solution then, is simple. URLs which contain multiple posts should be marked “noindex,follow” while individual posts should be marked “index,follow”. This should result in the content of each post only being in the search engine database once. I also found a post called A critical SEO Tip for WordPress which describes a way to accomplish this in WordPress. The slightly modified version of this solution which I have added to my WordPress theme’s header.php is below. Unless there are downsides to this approach that I don’t know of, I think every theme author should add something like this to their theme.

<?php
if (is_single() || is_page() || is_author()) {
echo "<meta name=\"robots\" content=\"index,follow\"/>\n";
} else {
echo "<meta name=\"robots\" content=\"noindex,follow\"/>\n";
}
?>