- standards-based presentation using XHTML and CSS;
- dynamic display and interaction using the Document Object Model;
- data interchange and manipulation using XML and XSLT;
- asynchronous data retrieval using XMLHttpRequest;
[…] An Ajax application eliminates the start-stop-start-stop nature of interaction on the Web by introducing an intermediary
"eBay this week is expanding its developers program, providing a single API schema to link to the e-commerce vendor’s site and adding other resources. The eBay Developers Program allows for development of third-party front ends to the eBay e-commerce site. The program has spawned more than 1,000 applications and 15,000 members who generate 1.7 billion Web services calls per month […]
A key improvement is unification around a single API schema to provide consistency when developing eBay applications. The API schema is featured in the eBay Web Services component of the program and is based on eBay’s current SOAP offering. It supports five interfaces: SOAP, XML, .Net, Java, and REST."
"I’m getting off my butt and putting together some web services for 43 Things, and I’ll hopefully have something to show by the [Web Service Mashup at the Emerging Technology Conference]. Thinking about it this week, I think I’m just going to build a REST API, and pass on the SOAP and XML-RPC formats for now… is that selfish of me?"
03/18/05 update: 43 Things Web Service API.
"Clearly, you can’t ‘submit’ the entire page, because that would destroy your map and other context. Google’s solution is to submit a hidden IFrame, then gather the search results from it. Let’s say, for example, that you simply wanted to go to Atlanta. […]
This HTML is loaded into the hidden IFrame which, when loaded, will punt a big chunk of XML back up to the outer frame’s _load() function. This is kind of a cool trick, because it saves the outer frame from having to determine when the IFrame is done loading.
I mentioned before that there was some advantage to be had by using a hidden IFrame over making direct XMLHttp requests. One of these is that the IFrame’s state affects the back button. So every time you do a search, it creates a new history entry. This creates an excellent user experience, because pressing the back button always takes you back to the last major action you performed (and the forward button works just as well).
I also think it bears noting that Google is pulling out all the stops to build rich web apps, no matter how weirdly they have to hack the browser to make them go. And I strongly believe that this is a trend that is here to stay — XHTML Strict/CSS/etc be damned. At the end of the day, what really matters to users is compelling apps that let them get their work done quickly."
"Suppose you have compiled a list of the 20 best sources of reviews on the web, and you want to leverage Google’s full text index to search these [through its API]. This isn’t possible to do, because Google allows only a single "site:" specified in a query.
Suppose you have structured data about people and their home pages, and you want to build a search joins your data with Google’s unstructured index. Sorry, not possible.
Second, the business model failings: when you use the Google API to get search results, you strip out all the value of the adwords model– the Google API doesn’t even expose advertisements, or have a meaningful revenue sharing model. This makes the Google API ideal for building toys that get 1000 hits a day, but bad for building meaningful commercial services."
I know I’m in a rut about this, but Google is making so much money with its core AdWords product that it’s not really taking its many other initiatives seriously from a business perspective (the most outrageous example of criminal neglect being Froogle). I’m betting on a monetization frenzy two quarters after the first signs of a slowdown (which I realize is going to take at least a year or two to happen).
The Starbucks of the Internet.
"But the challenge was to combine the data in such a way to make not only good looking maps, but ones that made sense. Mr. Tait said, “We always started with the data and often had two interesting variables or two variations of a single variable (density and number of or per capita and number of) that we wanted to show. They often get two different aspects of a phenomenon. For example, quarterbacks by state is shown in the cartograms as size equals per capita but it is also interesting to know number of so we colored them that way. For the bivariate choropleth maps (Golf and Olympic athletes) the desire was to get at economic factors helping explain golf course distribution in the one case and physical geographic factors helping explain athlete distribution in the other.""
I had missed the tempest in a teapot between Jot and SocialText, but whil catching up with these old news I found this mouthful from Jonathan D. Nolen:
"What it comes down to for me as a customer, really, is this: I don’t just want open source code. I want a partnership with an open company. Open source code and open data are just a minimum bar. You also have to provide channels of communication — and participate in them. And you have to be honest about your product: both its problems and its future directions. In the end, the open relationship with your customers will prove far more valuable (as well as more remunerative) than open source code alone."
Some open source projects are living dead while some closed source software vendors managed to create thriving communities around open access to data. I know which one is more important to me as a customer.
02/27/05 update: The Open Company Test.