You say tree, I say URI...
Tuesday, 21 October 2003
I can’t help but wonder if what Adam wants could be had using plain old HTTP by just defining a new format that is nothing but a list of links to stuff that’s in-scope for a query.
That way, when you want to load up your mobile device with the right restaurants from Zagat, you just perform your search and ask for that format back (using content negotiation), so that your client can remember which URIs are associated with it. Then, when you sync, it can go and grab them and save them for when you’re on that plane.
Do we need a new format here? RSS seems like it’s awfully close to the mark, with some extensions (including a better sync model).
More generally, I think we need one or more formats to allow Web applications to talk about the interfaces that they expose, so you can hang metadata off of them and build relationships between them. See here and here for previous attempts (at least one more is currently in the works ;).
Then, we need more intelligent and capable clients and intermediaries, so that we can take advantage of this extra information. See here and here.
My personal prototype for this was on a very different scale; my work at Akamai saw me designing an XML-based format (the precursor to URISpace) that allowed our customers to control some 13,000 Web servers spanning the globe with per-URI granularity, so that we could do some pretty cool stuff - and not just caching - on the edge. And it was all designed to be able to operate in a disconnected mode. Sound familiar?
To make it all real in the way that Adam wants, we’d probably need either a very strong vendor or a profile (a la WS-I), because otherwise most of the specs are just too wide open. But that’s another entry…