https://bugzilla.wikimedia.org/show_bug.cgi?id=25676
--- Comment #20 from Michael Dale <[email protected]> 2011-03-28 18:18:56 UTC --- (In reply to comment #19) > It is difficult to underestimate the level of incompetence out there when it > comes to the web. Your average developer has no idea how to write a library > that traps a 308 status. Generally people prefer a RPC-like model, with both > success and error statuses encoded into 200 OK responses. :( > > And, that's already what the rest of the MediaWiki API does yea... when we mentioned it a while back https://bugzilla.wikimedia.org/show_bug.cgi?id=17255#c3 we sort of reached a similar conclusion that HTTP protocol adaptations would be difficult. But ... the idea with protocol modifications is that is part of a more general effort to do something in a general purpose way that is more or less consistent across APIs. i.e it separates the 'transport handling' from the 'api query and response'. So the same transport code supports chunk uploads in the same way regardless if your uploading to youtube or wikimedia commons with javascript XHR, native browser upload handler or with a python script with a chunk upload handler shared library. There are tradeoffs either way, someone simply needs to make a decision. As long as there are no foreseen issues with supporting this protocol in wikimedias cluster setup ( ie we can pass along non-standard http headers, the system does not blow up with 308 response codes etc ) I would lean toward separating the transport layer into a more common shared protocol than something custom to mediawiki. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
