On Thu, Nov 12, 2009 at 3:55 PM, Herbert Van de Sompel hvdsomp@gmail.com wrote:
2.1. The plug-in detects a client's X-Accept-Datetime header, and returns the mediawiki page that was active at the datetime specified in the header. Same for images, actually. This effectively allows navigating (as in clicking links) a mediawiki collection as it existed in the past: as long as a client issues an X-Accept-Datetime header, matching history pages/images will be retrieved.
Doesn't the use of a header here violate the idea of each URL representing only one resource? The server will be returning totally different things for a GET to the same URL. That seems like it would cause all sorts of problems -- not only do caching proxies break (which I'd think by itself makes the feature unusable for users behind caching proxies), but how do you deal with things like bookmarking, or sending a link to a particular version of the page to someone? These would become impossible, unless the server goes to the extra effort to return a redirect.
It seems to me like a better path would be to have different URLs for different dates. The obvious way to do this would be to take an approach like OpenSearch, and provide a URL pattern in some standard format. Maybe the page could contain <link rel=oldversions> or such, with the client appending a query parameter to the given URL, say time=T where T is an ISO 8601 string.