This is the first entry to actually describe how a web services browser might work, at least as I imagine it. Remember, in this dream, a web services browser is primarily interacting with information, not user interface. It does have "pages" but it also has a local cache of information garnered from the web services to which these pages are bound and the two are distinct. Related, but distinct. In the next few entries, I'll discuss how an online/offline calendar might work since it is something I feel is sorely lacking from the web. Let's make the web services part of the Calendar really simple. There is a service to get activities for a date range. In addition, there are operations to add an activity, to modify an activity, and to delete an activity. Each activity can have notes, one or more assigned people, phone number, title, priority, start time and duration, external visibility, reminder attributes, category, and repeating characteristics if any. In short, mostly what is in Yahoo's calendar if they only surfaced it as a web service! This information can be thought of as a local XML store with documents for each activity and web service operations used...
Adam Bosworth's Weblog]

I've read a few posts from Adam Bosworth touching on his Web services browser concept, and I think I can now officially say that "I don't get it".  That is to say I understand what he wants, but I don't understand what we're missing here.  Don't we already have these functions?  Don't these tools already exist?  From a .NET perspective, isn't this a series of simple Web services that can be easily glued together using some simple front end applications or tools like InfoPath?  I think Adam is either on a plane of thought that I can't relate to, or he's underestimating the tools that are already out there to support Web services developers and consumers.  If someone thinks that they understand what Adam is saying and what I'm missing, please comment.