WAX
1 Comments
Over the last year or so I’ve started to take notice of a new breed of online applications. I think that web-apps, exposed API’s, mash-ups, widgets and so forth are a number of different views of the same overall trend. Namely:
Previously we would have said the business hosting the online service was a web site, or a web application. But what if the web was no longer the primary way in which it was accessed? For example, what exactly is the iTunes music store? If most people just accessed Gmail with a POP or IMAP interface, what would it be? What if the primary interface to Google Calendar was iCal, and not the web?
I’m going to put a stake in the ground and try to put a name to this thing: WAX. Web Application eXchange.
WAX consists of three core elements:
Web - not because it even has to have an HTTP interface, but because it usually does, and because this phenomenon is growing out of the Web community. HTTP has become the de-facto standard transport for applications, and almost all WAX apps use HTTP as their transport mechanism.
Application - because the core of the service is to provide some sort of functionality that might otherwise be provided with installed and licensed software, or just run on the desktop. WAX apps are more than just brochures on the web, and even content management systems don’t really qualify. This isn’t about publishing (unless its a publishing app, of course) - its about online software.
eXchange - because the online nature of the service works best and makes the most sense when it allows the user to collaborate or otherwise interact with other users who are also online. An online app that allows you to do something in isolation might as well be a desktop app. What makes an online spreadsheet or word processing document WAX is when it can be shared by people.
Where is WAX? Where are some good examples of WAXware?
Well, I was playing with Google Calendar and a beta of something called Spanning Sync. Now, Google has calendaring software which they happen to expose through a cool AJAX web interface. However, they also expose it through an open calendaring data exchange format called iCalendar. On my Mac I could subscribe to the iCalendar interface using iCal (the mac OS X calendar program) and see my Google calendar. However this is read-only.
Spanning Sync takes it a step further, by offering bidirectional sync between iCal and Google Calendar. Now if I enter an appointment in iCal it gets pushed up to Google. But wait, what if I’m sharing my Google calendar. Then someone else could be using it, also using Spanning Sync and iCal.
Suddenly we’re collaborating on the web, using Google Calendar. The only thing is - neither of us are actually going to the Google web site! Is it really a web application now? Well, not exactly - its really WAX.
A couple of implications of this idea:
On a business level, it does raise some questions about what models are sustainable. An advertising supported model doesn’t work when no one goes to the website to see the ads. The advertising model is why you can launch a Google search from anywhere (from the search bar in FireFox, for example), but you have to view the results on a Google search result web page. That’s because that’s where the ads are. Those search results will not be available via XML or JSON or whatever, so long as Google is working with their current business model. This implies that if WAX really takes off we’ll see more transaction-fee and subscription based business models.
On a technical level the concern with these kinds of integrations is that it creates dependency on a third party to deliver the service. In reality businesses and individuals make this compromise all the time - we rely on third parties for power, banking, payroll, HR, and so on, but this is a new area, so there’s reasonable grounds to pause before putting one’s mission critical systems in the hands of a startup “Web 2.0” company.
However, my prediction is these issues will be worked out sufficiently over time. WAX will allow businesses and application developers to collaboratively harness each others’ value, and should over time reduce the cost and complexity of developing sophisticated online applications.
- An online service that takes some silo of functionality and makes it available through many different means. This usually includes a web site, but can often involve many machine-readable formats such as XML-RPC, JSON, REST and so forth.
- A bunch of different client apps that connect it together: other websites, widgets / gadgets, full blown desktop apps or plug-ins.
Previously we would have said the business hosting the online service was a web site, or a web application. But what if the web was no longer the primary way in which it was accessed? For example, what exactly is the iTunes music store? If most people just accessed Gmail with a POP or IMAP interface, what would it be? What if the primary interface to Google Calendar was iCal, and not the web?
I’m going to put a stake in the ground and try to put a name to this thing: WAX. Web Application eXchange.
WAX consists of three core elements:
Web - not because it even has to have an HTTP interface, but because it usually does, and because this phenomenon is growing out of the Web community. HTTP has become the de-facto standard transport for applications, and almost all WAX apps use HTTP as their transport mechanism.
Application - because the core of the service is to provide some sort of functionality that might otherwise be provided with installed and licensed software, or just run on the desktop. WAX apps are more than just brochures on the web, and even content management systems don’t really qualify. This isn’t about publishing (unless its a publishing app, of course) - its about online software.
eXchange - because the online nature of the service works best and makes the most sense when it allows the user to collaborate or otherwise interact with other users who are also online. An online app that allows you to do something in isolation might as well be a desktop app. What makes an online spreadsheet or word processing document WAX is when it can be shared by people.
Where is WAX? Where are some good examples of WAXware?
Well, I was playing with Google Calendar and a beta of something called Spanning Sync. Now, Google has calendaring software which they happen to expose through a cool AJAX web interface. However, they also expose it through an open calendaring data exchange format called iCalendar. On my Mac I could subscribe to the iCalendar interface using iCal (the mac OS X calendar program) and see my Google calendar. However this is read-only.
Spanning Sync takes it a step further, by offering bidirectional sync between iCal and Google Calendar. Now if I enter an appointment in iCal it gets pushed up to Google. But wait, what if I’m sharing my Google calendar. Then someone else could be using it, also using Spanning Sync and iCal.
Suddenly we’re collaborating on the web, using Google Calendar. The only thing is - neither of us are actually going to the Google web site! Is it really a web application now? Well, not exactly - its really WAX.
A couple of implications of this idea:
On a business level, it does raise some questions about what models are sustainable. An advertising supported model doesn’t work when no one goes to the website to see the ads. The advertising model is why you can launch a Google search from anywhere (from the search bar in FireFox, for example), but you have to view the results on a Google search result web page. That’s because that’s where the ads are. Those search results will not be available via XML or JSON or whatever, so long as Google is working with their current business model. This implies that if WAX really takes off we’ll see more transaction-fee and subscription based business models.
On a technical level the concern with these kinds of integrations is that it creates dependency on a third party to deliver the service. In reality businesses and individuals make this compromise all the time - we rely on third parties for power, banking, payroll, HR, and so on, but this is a new area, so there’s reasonable grounds to pause before putting one’s mission critical systems in the hands of a startup “Web 2.0” company.
However, my prediction is these issues will be worked out sufficiently over time. WAX will allow businesses and application developers to collaboratively harness each others’ value, and should over time reduce the cost and complexity of developing sophisticated online applications.
Lon said... on March 6, 2007 9:46 PM:
