Norm on Names

From a post from Mark Baker, there's a fine post from Norm Walsh on names that you all should read - my favorite quote:

Contrary to what you may believe, there is nothing about the “http” URI scheme that requires use of the “http” protocol. And even where the “http” protocol is used, there's nothing about it that requires access to any particular machine.

On your desktop, your web browser may return things from its cache without ever hitting the web.

Erlang - the next buzz in web conversations

This post by Patrick Logan points to another post talking about Erlang and scalability. I've been hearing a lot about Erlang from the REST community recently and I've been thinking about all the things I could build with yet another web server that supposedly supports over 60,000 concurrent connections.

Rock 'Em Sock 'Em Robots

Ah, the good old days of Rock 'Em Sock 'Em Robots. When I was a kid this was a favorite game and it looks like Mattel has a new re-issue of the game.

The interesting thing about this particular page on Amazon is that this game is offered by three separate sellers, and Amazon is one of them. Before today, this was not possible due to the exclusivity contract Amazon was operating under. My team was only peripherally involved with the effort to make this happen, but watching the speed and professionalism of all the teams drilling into all the details, crossing the T's and dotting the I's, really made me proud. Not only did the people here work quickly and competently, but the software platform worked as designed.

Another interesting thing about that page, the customer reviews have multiple categories of stars - durability, fun, educational and overall - I never noticed that. Those are exactly the areas I look into when reviewing toys and games. Pretty cool.

Let the Rock 'Em Sock 'Em Robots competition begin.

RESTful Interface Description

The other day, a friend from Oz asked about IDL (interface definition language) for RESTful services (it turns out WSDL 2.0 has binding definitions that support all HTTP methods) and now there is this post from Phil Windley Crying Out for a RESTful Service Interface Description Language:

The only way that we’ll get to a place where Web 2.0 apps are more easily integrated is when we have a service interface description language and other metadata standards for RESTful services.

At the top of the post he links to another blog by Dave Rosenberg that says in part "To me the big opportunity of Web 2.0 development is the ability to create a better user experience based on features etc."

Following Phil's post is a comment starting with "What we need is a [...]".

Here's a suggestion - pick two services you would like to integrate, something that would result in real tangible value that you would actually use day-to-day, and try actually implementing these difficult integrations (and some are tricky) and write about the effort and the problems. That real effort with real implementation will surface the real problems that need solving. Crying out "you should do this" or "people need that" is just so much wishful theory talking.

In theory there is no difference between theory and practice. In practice there is.

The Web Is a Pipe

From The Web Is a Pipe:

Opportunity opens up when we use HTTP to connect our server infrastructure components together. If you use HTTP between your front-end web server and your back-end application server, suddenly you gain the ability to swap Apache for Lighttpd on demand without worrying about the FastCGI bits. Your application server won’t notice the difference. You can replace either Apache or Lighttpd with Pound or Pen. You can even replace them with some sort of hardware load balancer solution if that floats your boat.

Even better, when you use HTTP as the glue, you suddenly can use a whole host of tools to probe the various parts of your application. You can use curl to probe just your application server. Or even point a browser at it, assuming that you have a clear path through your firewalls and what not. And, if you’re really l33t, you can do a manual telnet and make just the request you need—with all the right headers—to simulate exactly a problematic client request.

Exactly. Using a web server as your application server means you can replace your application server with yet another web server.

HDR Coconut

big coconut
Originally uploaded by Haiku Garry.

I stumbled across this surreal photo of a coconut and was intrigued by the tag "HDR". What is "HDR" I thought? It turns out that HDR means high dynamic range. This is more than merely 32bits per color channel per pixel, it usually means capturing the full dynamic range. Most cameras can't do that, so the trick is to take three or more exposures and blend them together - called tone mapping or exposure mapping. Flickr is full of amazingly artistic photos with rich and deep colors. Many looks not quite right, almost as if they are a bit - but only a little bit - beyond current capabilities of computer graphics lighting models.
The HDR pools on Flickr have a lot of abandoned heavy iron cars from America's motor past, many photos of solitary houses, of disorderly mechanical/industrial buildings and one photo stream of an apparently abandoned castle.

Kaboodle

I found Kaboodle through a Google search alert (for 'social network shopping'), and for some reason I think the idea is really cool. It is sort of similar to Ta-Da lists from 37signals but more of a rich media list maker - wishlists, compare product data from different sites (very useful when hunting for a digital camera), assembling details on places to go for vacation (I could have used this last year...). Lots of uses come to mind.

The color scheme is orange and blue, like all good startups, but the site still looks fresh.

S3 support Virtual Hosting

This is good news - S3 supports the Host header in HTTP requests. I had been meaning to write about the security holes is storing different people's data within the same domain - as soon as two people host javascript, then 'cross site scripting' becomes possible within one host domain. This enhancement allows folks to trivially avoid that problem (assuming people want to host HTML and Javascript on S3 - not it's advertised purpose).

ACM Interview with Werner Vogels

I finally found time to read the ACM interview with Werner Vogels about Amazon and service oriented architecture (conducted by Jim Grey, no less). He talks a bit about Amazon history and a bit about how services affect development teams as well as the runtime and operational benefits.

Here's one of several 'lessons learned' that Werner recounts:

A second lesson is probably that by prohibiting direct database access by clients, you can make scaling and reliability improvements to your service state without involving your clients.

Interesting - since a database is also a service, what is the essential difference between direct 'database' access and direct 'service' access that improves the situation?

Another interesting comment:

Other lessons are related to how you access services: If you want to be able to aggregate services easily, if you want to insert advanced infrastructure techniques such as decentralized request routing or distributed request tracking, you need a single unified service-access mechanism.

Hmmm, the single unified access mechanism sounds like a protocol. I'm in the middle of building a new service and haven't been considering this - I wonder if I'm going to get in trouble. But I guess that's okay, since my business card does say Sr. Troublemaker...


Now this is the part that I like - as it involves my stuff!

About a million small and larger businesses sell on the Amazon platform. For example, if you go to one of the book pages, you will find that item is also available new or used from some of our many partners. These can be very small independent bookshops or larger retail operators that want to sell on our platform.

And onto REST...

Do we see that customers who develop applications using AWS care about REST or SOAP? Absolutely not! A small group of REST evangelists continue to use the Amazon Web Services numbers to drive that distinction, but we find that developers really just want to build their applications using the easiest toolkit they can find. They are not interested in what goes on the wire or how request URLs get constructed; they just want to build their applications.

Amber stones in the Northwest

Amber stones
Originally uploaded by dierken.

I've always been fascinated with minerals and gems, so this last Thursday I was very excited to go on a school field trip with my son to hunt for amber near Tiger Mountain.
There is a geologigist - Geology Bob - that conducts field trips for groups and schools to hunt for rocks, crystals, fossils and other cool things. From what I could hear (my ears are plugged up from a cold), back in the 70's he discovered a field of amber stones here in western Washington, which is astounding - there are only five places in North America that have amber deposits. Because he has been involved in local geology for quite a long time, he has received a permit to go onto state park land to conduct these geology tours for educational purposes. We learned about how amber is formed - ancient tree sap sinks into a swamp, gets covered in sand and mud, is pushed down into the Earth a quarter mile for ten million years, and then somehow surfaces again. It appears there are two earthquake faults in the area that are pushing together and squeezing material up to the surface. This area has coal, fossils and suprisingly some amber. Digging is fairly easy and when the shool kids find the shiny clear flakes and pebbles, they just holler with excitement - it was very fun. The class was full of third and fourth graders, and some of them were already planning on selling chunks of coal and real amber for a milllllion dollars on eBay. I just love that wild enthusiasm. They weren't even very disappointed to discover they would be lucky to get one or two cents - they figured they would need a hundred pounds, or maybe even five hundred pounds...

Microsoft is building a Google cluster

From Greg Linden's blog, a quote from Microsoft:

"the people who could build a viable [Web] services infrastructure of scale are companies that have both the will and the capacity to invest staggering amounts of money."

Hmm. I suppose that would exclude Google, BitTorrent and the Web itself. Unless they meant "the people that need to catch up will need staggering amounts of money, otherwise they lose".

dojo.storage: Client-Side Storage

From Ajaxian, here is a post about
offline access and client-side storage via Dojo. We are getting close to the tipping point for disconnected use and client-side state - and with the strength of the REST buzz (I can't believe how many people are actually applying REST!) this really bodes well for the next few years of Internet-scale application development. If nothing else, at least it's yet another way to route around the damage that is the Win32 API.

Pubsub .vs. polling - again

This is a great read from Bob Wyman on Dave Winer's comments about polling compared to notification :
From As I May Think...: Dave Winer: Show me that mathematical proof!

Dave's lack of understanding of the issues related to scaling can be seen in the history of the weblogs.com site that he struggled to build and maintain for so long. That site takes "pings" from blogs and then consolidates them into tremendous "change lists" which must be polled. Essentially, this site converts an efficient push-based update notification system (pinging) into an inefficient polling based system. Weblogs.com, as Dave built it, didn't even support common methods like eTags or RFC3229+feed to improve polling efficiency and scaling. The result was that it simply didn't scale and was frequently incapable of providing the service levels that people expected. Only now that Verisign has taken over the site and dedicated much better engineering staff and much more hardware, has the weblogs.com service begun to be somewhat useful again. However, since weblogs.com is still based on the terribly inefficient polling of change-lists that Dave supports, it is still a far cry from being what it might be.

Ouch. But I did like the nod to KnowNow and mod-pubsub. Not sure if mod-pubsub is still alive and kicking though.

Best Google Image

The latest home page graphic from Google is my absolute favorite -

Delta feeds - RFC3229+feed

About a year and a half ago, Bob Wyman was instrumental in defining an approach to greatly reduce the load and bandwidth used by applications that polled for changes to RSS/Atom feeds.
The other week, he noted that Microsoft will support the RFC3229+feed approach as well - which is good.

The only problem I have with this approach is that I think it is simpler to use hyperlinks, and I haven't seen a real comparison between the two. Both approaches have the client application maintain state of what data was last retrieved, but using hyperlinks has more chances for pre-existing caching servers to work without modification. I think the Atom protocol has defined something like this, but I couldn't follow the email threads.

To use hyperlinks, the data returned in a feed would have a link to the 'next' (more recently changed) posts. The client would then follow that link, which would either be empty (and optionally have a cache-control header to indicate how long to wait before checking again) or have more data - along with another 'next' link. The client just keeps following the links. The client would have two URIs - the original, well-known location that new readers start from, and the changing one which is the set of data most recently retrieved by that particular client. The server decides what the 'next' link is and what it contains - the data would be very cachable across all clients, merely by checking the URI.
The downside of this approach is the need to put the link within the content of the response - or add a response header for that location if the content isn't easily extended.

I put together a sample application that shows how this works - this is a simple html/javascript chat client, this is a link to the list of messages.

Broken as Designed

Sith Obasanjo in Broken as Designed can't decide which way is away from the dark side -

"However I do think some Web/REST advocates need to look around and realize what's happening on the Web instead of arguing from an 'ideal' or 'theoretical' perspective."

The Web advocates need to realize what's happening on the Web??

Okay, we all know some resources have broken content-type headers when you retrieve them. Others don't. Some clients never use content-type correctly, others do and many use heuristics. That's okay. Just do your homework - and part of that is to read the TAG finding and use it where appropriate - and be a good web citizen. That's simply practical advice based on practice. The "don't use content-type" is a theory that is unproven in practice.

Update - it looks like Dare found breakage in Cookies as well, but after further investigation it turned out to be a problem with the data returned by the server. But if the bloggers using RSS can't correctly control this Cookie response header - would we have no choice but to drop support for that header as well, as suggested for the Content-Type header? I mean, the theory of Cookies is all well and good, but if you look around to what the major players like MSN are actually doing, who are we to stick with something broken as designed merely because of theory?

Persistent Search and OpenSearch

It looks likes there's more interest (again) on saved searches and search alerts -
unto.net - Persistent Search and OpenSearch

Hopefully things have changed since I last reviewed this space in 2004.

Content-Type is dead

What a simply stellar idea here - Hixie's Natural Log: Content-Type is dead - browsers were broken, server configs are broken, so there can't possibly be any reason to use this header. The browser can't use it, so nothing else should either.

I think it may be time to retire the Content-Type header, putting to sleep the myth that it is in any way authoritative, and instead have well-defined content-sniffing rules for Web content.

You shouldn't throw away the Content-Type header even if server configs aren't easily controllable by the author. Go ahead and do the right thing - use the document context and tags as a hint on how to handle the content, use the content-type along with the content itself. There's nothing wrong with applications retrieving the resources referenced by an img tag to assume that the retrieved content is an image.
The only arguments people may have is when there is little context available when retrieving content (no hypertext source document) and the retrieved content could be interpreted in several ways.

Telomolecular Nanocircles

This description of telomere technology from Telomolecular looks interesting:

Synthetic DNA Nanocircles are a biomedical nanotechnology invented by Dr. Eric Kool and colleagues of Stanford University. These nanometer-sized circular DNAs have been shown to elongate chromosomal telomeres in vitro. They consist of DNA bases arranged in a sequence that templates the lengthening of telomeres by repeated addition of new TTAGGG sequences. Nanocircles have shown promise in telomere elongation in human tissues. By combining nanocircles with new proprietary gene therapy and delivery technologies, Telomolecular believes that nanocircles might work efficiently in living animals.

Google Base Storms Into Europe

From webpronews.com:

"The search advertising company will have a lot of catching up to do in Europe, where Amazon has relationships with businesses like UK-based Marks and Spencer. Google may have to pitch something beyond its online capabilities, though, according to the FT report:

One big UK retailer with no online presence said on Wednesday that Google's retail offer would be of interest if the internet company could also arrange for distribution. This potentially huge task has raised doubts about the long-term business models of other online retailers such as Amazon.com.

Doubts over Amazon's distribution don't have much grounding in reality. The company has built up its distribution network over the past decade and does have some knowledge in the area. Google's expertise at distribution probably does not go beyond making a change in a router's access control list and opening up a website. "

I like that last bit - Google's expertise at distribution probably does not go beyond making a change in a router's access control list and opening up a website.

The article goes on to suggest that Google team up with UPS for the distribution center. I wonder if that would work.