https://bugzilla.wikimedia.org/show_bug.cgi?id=34778
--- Comment #37 from Tim Starling <[email protected]> --- (In reply to comment #34) > Also, it is hard to see > what incentives browser manufacturers have to natively implement > Memento's datetime negotiation as long as there is no critical mass of > servers supporting it. Failed attempts to get the attention of Mozilla > and Opera support this consideration, but if you have experience otherwise, > then any assistance you might give would be greatly appreciated. As I said, the browser manufacturers have a long history of implementing features in advance of their use on the web. For example, the lead taken by Firefox and Opera in the introduction of various HTML 5 features. If you want to get Mozilla's attention, you could start by filing a bug: https://bugzilla.mozilla.org/enter_bug.cgi > * Caching 302 responses from a TimeGate will yield marginal benefit, if any: Indeed. The high cardinality of TimeGate requests is a problem for efficient implementation. It is possible to imagine a protocol for retrieval of historical revisions which would not have this problem. > This comment regarding poor software quality comes as a big surprise > as we have invested very significant resources to improve the initial > code base, through many iterations, in response to feedback from > MediaWiki people. The comments above show that the code quality started out being terrible. It has improved greatly. Now, it is only poor. It still has some way to go before it is acceptable for WMF deployment (even if it was something we wanted). > This is the first time we hear about the false > assumption re mmAcceptDateTime(). Our developer Harihar Shankar states > the following with this regard: > "I am determining if the current resource is a version of an article > by looking at the URL and check if there is "oldid" in it. This is > definitely not the best way to do it, but I looked extensively in > their documentation and I could not find a better alternative. This > issue has not been brought up by the code reviewers so far." > We would be very interested in learning what the appropriate approach > is. And we are interested in hearing about other problems with the > code. In both cases, we will be most happy to make required changes to > bring the code to the desired quality level. If the necessary interfaces really are missing, then the developer's response should be to introduce them. But I think using an ArticleViewHeader hook and calling getOldID() on the Article object passed to the hook would be a reasonable way to do it. Then the hook will only be triggered on actual views of ordinary wiki pages, and the oldid will be the same one used by Article.php, which would be an improvement. $wgRequest should not be used at all, nor "new RequestContext". You can get what information you need from the Article methods. Instead of $wgOut, you can get an OutputPage object from $article->getContext()->getOutput(), and instead of $wgRequest, you can use $article->getContext()->getRequest(). Nothing should ever call exit(), including Special:TimeGate and Special:TimeMap. You can use OutputPage::disable() to customise the output. -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug. You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
