I've started this Web 2.0 client technology series to candidly discuss the real programming issues in the Web 2.0 world. Beyond the trivial "Hello, World", the irrelevant "Create A Circle With A Slider", or the juvenile game examples; I wanted to provide insight into what we needed to do to create Mashup clients on top of the industry's Web 2.0 client technologies from Apple, Microsoft, Google, Sun, Mozilla, Opera, Yahoo!, and the others.

Just in case you're not quite sure what a Mashup is: "It’s been called the essence of Web 2.0. It’s the ability to combine pieces of different web sites to create something new, something meaningful.  Something for you and the people who have your tastes. Your social network. Not some mass market portal built by corporate programmers who think that they know you and your personal tastes.

 

Referred to as a composite web site by some and Mashup site by others, we call it amalgamating web data through the process of transcoding. Whatever. It’s about giving you the data that you want on your mobile phone or desktop browser. It’s Web 2.0. It’s about you."

A little more concretely, here's a screen shot of our Mashup developer tools-- from way back in 2003-- extracting an HTML <TABLE> of Wi-FI coffee houses and dynamically transforming that HTML element for use in a mobile site. So a Mashup is all about extracting remote HTML and inserting into a new site. That remote HTML can come from 1 or more sites, or web services, or databases-- from wherever-- and transforming them into different HTML as needed.

Of course, there are more details to this process such as fixing the incoming HTML or putting into a WML site but those are enhanced features built on top of the idea of extracting remote snippets to create something new...

copyright issues and DDOS aside.

Since we probably have the most knowledge of Web 2.0 environments-- and we want end users to be able to realize the potential of Web 2.0 and Web 3.0-- we feel that sharing our knowledge is the best thing for our company's financial health and to ensure that programmers are able to meet these new challenges and not get suckered into rewriting their old code for no good reason. Just how many clock widgets do we need?

So after blogging about each of the Web 2.0 client technologies, I'll follow-up with what's needed technically to create a Mashup client so that you can better measure just how complex your Web 2.0 project will be.

So first, let's black box the Mashup server piece and just conceptualize that it's a web server that knows how to extract snippets of HTML from other sites. Cool.

Now let's focus on what's needed to get that content from the web server using these newfangled Web 2.0 clients. You might be shocked :-(

We need to support the following:

1. 1.Access the Mashup server just like we would a normal web server using HTTP
   

2. 2.The Mashup server can give us the remote HTML snippets as a whole new document or perhaps just as a document fragment using XHR.
   Don't forget, a remote snippet(s) can be transformed, filtered, and aggregated by the server as needed but conceptually it's still a remote snippet(s) of HTML
   

3. 3.The Mashup server can give us the mashed-up document or fragment as HTML, XML, RSS, or JSON
   

4. 4.The client has to be able to get updates either when the remote HTML snippets change or periodically when the user wants an update
   

5. 5.The client can pull the updates using AJAX or the server can push the content updates using Comet
   

6. 6.The client has to implement a strategy for handling HTML links to other content
   

7. 7.The client has to be easily accessible to the user to see or hear the content updates
   

8. 8.Distributing the client and handling software updates
   

So those are the core requirements of a Mashup client.

We'll use this list to see how each of the Web 2.0 client technologies can handle them. With the goal being that you'll be better prepared for your Web 2.0 project.