I'd like to expound on Herbert's point below. We chose 302/Location style CN (instead of 200/Content-Location) to provide more transparency in the process. So I can link to:
http://en.wikipedia.org/wiki/The_Cribs but if I have my Memento FF add-on set to: X-Accept-Datetime: {Tue, 29 January 2009 11:41:00 GMT} I'll get redirected to: http://en.wikipedia.org/w/index.php?title=The_Cribs&oldid=187673999 which will show up in my browser's location bar and thus linking, sharing, etc. will be done with the correct "old" URI. This would not be the case with 200/Content-Location style CN. If the old version is not what the user wants to link, share, etc., then turning off the Memento add-on and doing a reload (possibly a shift-reload) will cause FF to correctly go back to the original URI (b/c FF does the right thing w/ the 302 semantics that say you should reuse the original URI). Wikipedia is sort of a special case in that the URI: http://en.wikipedia.org/wiki/The_Cribs will return both the current representation as well as an older representation (if CN is requested by the client). That is, that URI is both URI-R and URI-G in the parlance of: http://www.mementoweb.org/guide/http/local/ Most servers that are not hooked to a CMS (like a wiki) will have URI-G be a separate URI, presumably in a separate archive. See: http://www.mementoweb.org/guide/http/remote/ There is already support for caching & CN, see: http://httpd.apache.org/docs/2.3/content-negotiation.html#caching http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.6 Of course, the current caches don't know about "X-Accept-Datetime", but that can come in the future (esp. when an RFC is written and the "X-" are removed from the various headers introduced by Memento). I'm not sure if they'll need to be aware of "Accept-Datetime" specifically, or (hopefully) they'll do the right thing with whatever values are returned in the "Vary" response header. We'll see. The goal of introducing a 5th dimension for CN (to complement type, encoding, language & charset) is that we are more likely to integrate with the existing http infrastructure. More so, we suspect, than introducing an RPC-like convention of arguments tacked onto URIs (e.g., "foo?datetime=xxx" or "foo?datetime=now") or overloading URI fragments. regards, Michael On Fri, 13 Nov 2009, Herbert Van de Sompel wrote: > On Nov 13, 2009, at 2:08, Daniel Kinzler <[email protected]> wrote: > >> Aryeh Gregor schrieb: >>> 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. >> >> How about doing both? If a X-Datetime-Accept header is received, it >> could >> trigger a 302 redirect, pointing at a url that specifies the desired >> point in time. > > This is exactly what we do in Memento and with the plug-in: datetime > content negotiation (X-Accept-Datetime header) on the generic URI > (say /clock in wikipedia) followed by a 302 redirect to the time- > specific URI (title="clock"&oldid=123456 in wikipedia). The generic > URI is always only serving the current version of the page; the > history URIs are serving the history pages. > > Herbert > > >> >> -- daniel >> >> _______________________________________________ >> Wikitech-l mailing list >> [email protected] >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > ---- Michael L. Nelson [email protected] http://www.cs.odu.edu/~mln/ Dept of Computer Science, Old Dominion University, Norfolk VA 23529 +1 757 683 6393 +1 757 683 4900 (f) _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
