Son of Smart Tags

Interesting, I never thought of Amazon doing that. From Better Living Through Software

A content provider (such as Amazon) who wishes to annotate users pages should be able to implement it once, using open standards, and have it work in Google, MSN, or Yahoo. Users should be able to chose whichever content providers they want, and it should be totally open.

So Joshua mentions users and content providers, but not authors. There's always that tension between authors having ultimate control, and users having ultimate control. There can be only one.

Even if you tried to use markup to indicate which sections of a document were 'annotatable', end users will still want non-marked up documents to have annotations. Identifying a region of a display to place annotations might work for some uses, but in-place links and coloration are extremely user friendly much more so than a parking lot in a side banner.

And what about non-HTML document formats? Sure, Microsoft has MS-Office Smart Tags, but who's doing the RSS (Really Super Smart) tags? What about SMIL? Or media playlists? Should the Web stay within the bounds of what transclusion supports? Or should it go beyond that to enable client applications to transform documents outside the control of the author? And what will be possible when non-HTML client applications start doing this?

Hunter S. Thompson dies

Terrible news.
Hunter S. Thompson dies

When the going gets weird, the weird turn pro. And when something like this happens, we've gone beyond weird.

Phil Windley's Technometria Strawman

Oh dear. Phil, Phil, Phil...

Phil Windley's Technometria blog has an interesting application of state management via continuations. Unfortunately he uses a strawman "Web application" to demonstrate how to solve a problem that doesn't actually exist.

Supposed I asked you to build a program to grab the current exchange rates from the Federal Reserve Bank in New York (FRBNY) in XML, prompt the user for the currency to exchange dollars for, then prompt the user for the dollars to convert, and then display the result. You might write a program that looks like this:

1. get the rates from the Federal Reserve Bank
   
2. show the first prompt and record the currency choice
   
3. show the second prompt and record the dollar amount
   
4. query the XML to extract the right information using the user input
   
5. calculate the result and display it
   

[...]

Now, suppose I asked you to convert your program to a Web application. Still a five minute job? Hardy, and the increase in time is more than just the problem of building the Web pages. What you’d probably do is put each of those steps into a separate script and then bind them all together with a little state machine in the CGI program that jumped to the right script based on state variables that you encoded in the URL, a hidden field, or a cookie. Sadly, it wouldn’t end up looking anything like the program that you’d write if you were just grabbing the input from a terminal.

To be honest, if asked to build that program, I wouldn't do it in that sequence (don't block on retrieving a remote resource 'just in case' you might need it) and I'd gather all user input in one shot. Sure, command line consoles are broken in that regard but Web applications are not. The problem I have is the "you'd probably put each of those steps into a separate script..." part. First, it's a horrible user experience splitting things up that way and secondly you only need a single resource to represent the conversion of a currency value. Build your application around a decent resource model and this 'problem' evaporates.

There isn't a problem with Web applications that need continuations - although they are an interesting way to manage state - but there is a problem with they way people build Web applications with older tools. And articles presenting a poor example as if it were 'best practices' or 'everybody does it this way' don't help.

Topix.net - The Incremental Web

Skrenta always has something though-provoking - this time about streaming pub/sub topics and surfing the leading edge of the Web - The Incremental Web

It's not appropriate to try to stream this incremental info with keyword searches. It just doesn't work. Say you want a feed of interesting news about Google. A while back I posted something on this blog about Google which you'd probably want to see in such a feed. But the rest of the articles here are not about Google. So you don't want to subscribe to blog.topix if you just want news about Google. But a keyword search for "google" isn't going to deliver a useful experience either -- there are far too many stray mentions of "google" on the web every day. To get a relevant news feed about Google, you either have to have people read everything for you and edit away all the junk, or find an algorithmic technique to do the same.

I agree that simple keyword searches may not be the best, but keywords and tags can be one of several methods to define the subject of interest or the topic to subscribe to - it's the subject or topic that's the slippery beast.

Contract first - dessert topping or floor wax?

From Dare about how easy it is to break interoperability by starting with service contracts

"This isn't theoretical, more than once while I was the program manager for XML Schema technologies in the .NET Framework I had to take conference calls with customers who'd been converted to the 'contract first' religion only to find out that toolkits simply couldn't handle a lot of the constructs they were putting in their schemas.Those conversations were never easy. "

My first reaction was to point out that maybe the toolkit itself might be an obstacle to building a large interoperable and interoperating system. Then I thought I should at least try to figure out what Dare might mean by 'interoperable'. Perhaps his concern is to build a low-effort adapter to existing software and existing toolkits. My idea of interoperable is to maximize the number of other parties your software interacts with and only secondarily minimizing the work to plug into that network.

Joel's Cup o' Java: REST is fun, but I still prefer SOAP

I think some practical integration experience may be needed here...

Joel's Cup o' Java: REST is fun, but I still prefer SOAP

Let's see what we have here

1. I can use existing web service toolkits and APIs. Once the interface is defined, I can switch from Axis to JAX-RPC to SAAJ, with my client none the wiser.
   
2. The client programmers can also choose from various existing technologies. These guys are usually friends of mine, so I enjoy making their life easier.
   
3. I can take advantage of future SOAP-related advances and technologies. If my company purchases a blazing fast web services stack, I most certainly want to use it.
   
4. I think that RPC will continue to be the basic building block of SOA. After all, it has been for OO.
   

In short, I embrace SOAP, or any standard, because it gives me lots of options, both present and future. And I like having options.

I can use existing web service toolkits and APIs. The same holds true for a direct HTTP approach.

Once the interface is defined, ... Ah, yes, the old "I'm in control of the interface" ploy...

The client programmers can also choose from various existing technologies. The same holds true for a direct HTTP approach.

These guys are usually friends of mine, so I enjoy making their life easier. With an HTTP approach, 'these guys' are usually a swarming legion, so I enjoy making more lives easier.

I can take advantage of future SOAP-related advances and technologies. Hmmm, same holds true for a direct HTTP approach. Although using advances that have already occurred is my preference.

I think that RPC will continue to be the basic building block of SOA. After all, it has been for OO. You may want to consider that OO is not planetary scale. And neither is open-ended RPC.

I embrace SOAP, or any standard, because it gives me lots of options ... SOAP is flexible. Like a rope. Just be careful not to hang yourself.