https://bugzilla.wikimedia.org/show_bug.cgi?id=22881
--- Comment #25 from Vitaliy Filippov <[email protected]> 2011-08-26 16:43:29 UTC --- (In reply to comment #24) > Conformance to the site style > <http://www.mediawiki.org/wiki/Manual:Coding_conventions> > is a requirement for core code contributions. I'll run my modifications through the tool. > I'm not sure what the point is of this multipart/related document type: is > there some client that can read it? The exports appear to be sent out with > HTTP > headers specifying Content-Type: application/xml, but with a body that is > plainly not XML, rather it is this MIME message format with headers embedded > in > the body text. > > It seems like zip would have been a better choice. The wording of the messages > which enable this multipart format certainly don't warn the user that what > they > are going to get will be so exotic. Oh, thanks. I've not thinked about zip. I agree that multipart is very exotic. For some reason, it was the first "archive" type I thinked of. > What does this: > > /*op-patch|TS|2010-04-26|HaloACL|SafeTitle|start*/ > > signify? It is wrapped around some strange-looking code. Is it meant to be > there? No... It's from other patch (access control extension). Sorry. > The 5000-page limit in SpecialExport::getPagesFromCategory() appears to have > been removed without explanation. Also, SpecialExport::rgetPagesFromCategory() > appears to have no recursion depth limit. I think any hard-coded limits are bad, and they were hard-coded... I've just removed them as it seemed the easiest way. Recursion limit is harmful for small/intranet MW installations - users often create deep category hierarchies and want to export them :) and there is relatively little amount of pages, so the performance doesn't count. 5000 pages limit is harmful for example for exporting full wiki content. These limits should probably be on parametrized on $wgSomething... > It's probably feasible to use the upload timestamp of the old image version to > generate the archive name, but it would need to be done with a bit more care > and analysis than I see here. For example, LocalFileRestoreBatch::execute() > appears to need patching. Deployment would be difficult since it would break > if > MediaWiki is downgraded or run with multiple versions on the same database. > > It would be simpler, and head off potential future problems with analysis of > image filesystems, if the archive names could be changed to a completely > different regime, adding some marker to show whether they were generated the > old way or the new way. Very reasonable. I'll change my modifications according to these remarks. Zip is really a very good idea :) -- 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
