• Categories

  • Wayback Machine

  • My Defunct Podcast

    The Bungee Line was an audio podcast for web developers, covering web API's, software development, and the creation of richly interactive web applications.

    podcast feed  Main Feed

On API Replication and Web App Compatability


Commandeering Applications by Replicating APIs

I recently met with Jesse Stay to discuss some plans and ideas I have been working on at Mozy. As expected, Jesse’s insights and feedback were tremendously valuable. (Thanks, Jesse!)

Tweetie API endpoint config on iPhoneOne of the items Jesse directed my attention toward was the recent implementations of the Twitter API by three different sites: WordPress.com (the host of this blog), Tumblr (another popular blog hosting service), and identi.ca (a prominent Twitter alternative which has supported the Twitter API since 2008). By providing 100% API compatibility with Twitter, people can use any application built for Twitter with these other services (as long as the app allows you to modify the service URI/endpoint it uses). Because services survive or wither based on use, supporting a popular and relevant API can instantly yield a slew of applications to support users better. As a result of their work, WordPress.com has gained applications like the iPhone application Tweetie. Although many of the applications for Twitter currently do not allow you to modify the API endpoint (Tweetdeck, for example), most developers want more users, and API-level compatibility makes it short work for developers to support your service. I suspect that soon, nearly all applications created for Twitter will let you modify or add to the default API endpoint.

This got me to thinking about GroupWise, Novell’s strong alternative to Microsoft Exchange.

Novell: Align with Google for Developers

Novell GroupWise has a complete web API, and has for quite some time. Unfortunately, Novell seems to neglect developers these days–especially in their legacy products (as evidenced by GroupWise having only a SOAP API). Aside from their list of close partners, few developers use the GroupWise API.

Google Code logoMeanwhile, with Google’s enormous cachet with developers, numerous applications support Google’s collaboration-related APIs (such as Contacts). Perhaps even more importantly, developers can easily integrate Google’s API into new and existing apps through the numerous source code libraries available for Google’s various API’s (again, see Contacts, this time for the list of libs). Google’s Atom-based REST API’s are popular, well-understood, and widely used.

Consequently, Novell has an opportunity to serve their dwindling fan base better: replicate the Google API’s that are most relevant to GroupWise. Make it so that developers can easily adapt their apps to serve GroupWise, and so that end users can select from a wider assortment of 3rd party apps. This would give nothing over to Google that they don’t already have. It can only increase the relevance and extend the life of Novell’s venerable old product.

It also makes it possible for Novell to get on board with the biggest technology trend of the latter half of the last decade…

GroupWise in the Cloud

Since my time at Bungee Labs, I have been considering how Novell could offer GroupWise as a hosted SaaS offering as a way of acquiring aspiring new companies. As Salesforce has shown well, small is beautiful, and there is big business in the “No Software” proposition. This is where GroupWise competes (entirely ineffectively) with Gmail (“Google Mail,” actually) and its related collaboration components. It’s very easy to set up a Gmail account that uses your own company’s mail@domain. You can’t do that with GroupWise today.

But GroupWise does have something that Google lacks: a rich client. With all the apps that Google enjoys, none do a complete enough job of unifying all the typical collaboration features of an enterprise collaboration suite. With legacy collaboration being such an unsexy subject in the age of the social web, it seems unlikely that Google will re-solve some of these relatively mundane features. Finally, although there is a de facto rule about “everything through the web,” that does not mean “everything in the browser.” GroupWise has browser-based access, but it also has a full client that works online as well as offline, giving Novell a complete end-to-end advantage.

So put it all together–SaaS + Google API compatibility–and Novell has a viable technical path for GroupWise. All that remains is to figure out a  freemium model that can viably compete with Google. (This is where I clock out.)

Note I realize that it’s kind of cheap to sit back and throw out directives for how some other company should manage its API strategy while sparing any mention of the company over which I may have actual influence. Some of the above thinking applies to our planning at Mozy. However, we do not offer a public API (yet), so it’s a challenge to directly discuss this subject without getting mired in caveats and cautionary or indefinite statements. If you have any more than a casual interest in where Mozy is heading with our API, please contact me by commenting on this post.

Advertisements

Personal Cloud: A Microsoft Employee’s Take


An interesting and well articulated take on Personal Cloud from Vu Ha, a Microsoft engineer, states:

I believe that there is an excellent opportunity to build an open user-centered data platform that comprehensively addresses data silo and privacy issues, and thus catalyzes dramatic improvement in agent applications.

Me, too!

I recommend checking out his post.

Nat Friedman & the Personal Cloud: “Personal data warehouse”


Ximian co-founder and intrepid technologist with SUSE Linux, Nat Friedman recently blogged about a “Personal data warehouse,” stating:

What I want is a giant elastic bit bucket in the cloud, with a powerful search engine on top of it.

He goes on to describe several capabilities that he wants the search capabilities to have, essentially bringing together several disparate services available on the web today–such as face recognition (Polar Rose) and Optical Character Recognition  (OCR, the simplest form right now may be Evernote‘s)–in order to make his data imminently accessible and usable.

Nat describes several other aspects, all of which in my view comprise not a single service, but a data platform. This Personal Cloud concept really cannot be delivered well by a single service provider–you don’t want it to be. Once you have your personal data in the cloud, the next step is to have a selection of relevant applications to choose from for helping you to manage your Personal Cloud. That means APIs that allow developers to offer best-of-breed services, such as face recognition, as applications that you can use with your cloud-hosted personal data.

All of that reminds me that I really need to write up a post about the necessity for data owners (you and me as individuals) having ultimate control over who can access our data (and what data they can access).

More Cloudy Thoughts: Protecting Your Lifestream


So there is a huge rift between how we work in the cloud-based, online world and our long-established storage media-centric behaviors. We accept it today, But that’s about to change.
Me, October 6, 2009

Only a completely self-absorbed, arrogant bastard would quote himself as the opener to his own blog post.
–Me, today

In discussing online backup in the context of the Personal Cloud, I related how cloud-based sites & services like Twitter, Facebook, Gmail and Hotmail have been shifting our expectations. More and more, we expect to be able to access our stuff from anywhere. Email services are doing this even moreso, since they generally allow you to work online as well as sync up before going offline. But I omitted something that is of key importance when it comes to preserving one’s personal data. How are you protecting all your stuff that you do in the cloud?

Say you’re using an online backup service like Mozy (and I commend you for doing so), that means that you have protected the bulk of your personal data…arguably your most important data. But there is also your lifestream data.

Lifestream (noun):

In it’s simplest form it’s a chronological aggregated view of your life activities both online and offline. It is only limited by the content and sources that you use to define it.
Lifestream blog, which is someone else‘s blog

My lifestream is dispersed across many services around the web. Every day, I use Facebook, Gmail, Twitter, Delicious, WordPress.com, and a host of other cloud-based services.

The recent T-Mobile Sidekick debacle, brought to you by our always-entertaining friends at Microsoft, resulted in a lot of backlash regarding keeping stuff in the cloud. Personally, I think that the anti-cloud hysteria it has spawned is overblown. Real people were indeed affected severely, but you can find much better reasons to be wary of the cloud. For example, the future of many Internet start-ups that provide cloud services hangs in the balance sheets of venture capital firms. When a VC firm deems a start-up as nonviable, sometimes there is little time before the lights go out and whatever data it hosted for you effectively evaporates. Now what?

Backupify is one interesting service that addresses this. I’m trying it out right now to see how it does with backing up my Twitter data. (That’s the free part of their service. If I like it, maybe I’ll expand how I use it.) I wonder who else offers this kind of service…

Note I confess to having a shameless ulterior motive for posting about Backupify. (And I think that they should consider adding WordPress.com to their list of target sites.)