https://bugzilla.wikimedia.org/show_bug.cgi?id=17983
--- Comment #3 from Krinkle <krinklem...@gmail.com> 2010-04-25 16:27:09 UTC --- (In reply to comment #2) > (In reply to comment #1) > > This could for example be used to patrol all edits from a certain page > > (imagine > > users making 20 edits, or an edit war whatever). > > Is such a thing really necessary in the first place? Surely it is sufficient > to > patrol the latest "good" revision to the page and then ignore the others. Unlike FlaggedRevisions, the RCPatrol-system works different. Not better or worse, but different. Patrolling is per edit, FlaggedRevisions is per page. For two reasons I say no. 1) For example, imagine a trusted user doing a good edit to a page. That would be marked as patrolled, or maybe autopatrolled if it's a sysop. This does not mean the vandalistic edit made 5 minutes earlier is OK. 2) When filtering recent changes as for example "anonymous unpatrolled edits", then earlier edits to pages stay in the list (as they should) so only marking the latest one would not make sense and clutters up that feed all together. But anyhow, I could imagine dozens other examples where batch operations would come in handy and save some work. To loosely quote myself from IRC yesterday: " It would not only save N-times a HTTP request, N-times a loop to check and verify the results for errors and N-times a database query on the server. So it wouldn't just move the loop from the API-user to the server, I think it would erase such a loop alltogether. AFAIK a database query can SELECT and UPDATE multiple items at once." But then again, I'm not thát familiar with the wikimedia backend to know if it would save resources. -- Krinkle -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
