SUL discussion could perhaps be broken off into another thread?
On 8/13/07, Andrew Garrett andrew@epstone.net wrote:
On 8/13/07, Simetrical Simetrical+wikilist@gmail.com wrote:
This much complexity in blocking definitely isn't a good idea for core.
I'm not sure what's so incredibly complicated about replacing two arbitrary flags with three or four well-structured, nullable fields.
As far as I can see, you'll reduce the number of flags from four to two, while increasing the number of fields from three to five or six or seven or something. That doesn't look like a decrease in complexity. If you were to ask why we don't replace the two permission-specific flags (createaccount/email -- the latter not even being a proper permission) with a generic permission-selection mechanism that would allow blocking any existing permission the user has, matched against a global whitelist (no blocking 'read' on Wikimedia projects!): that might be a good core feature. It would unify some existing features while fulfilling multiple other feature requests. But to also allow the permission to apply to individual pages/users/etc. is unnecessarily complex for core, and arguably not desirable altogether.
A more detailed proposal of exactly what schema and UI changes will be made might allow more explicit criticism and countersuggestions.
On 8/13/07, Andrew Garrett andrew@epstone.net wrote:
It is /possible/ to implement this functionality in an extension, using the existing userCan hook. However, I think that, from a performance perspective, it would be a lot slower to do so (as the original blocking system check would have to be performed, as well as that for the improved system.
To which the solution is to adjust hooks so that's not the case. Ideally, we should probably allow extensions to easily override any query in the software for exactly this reason, to avoid having to throw away or repeat queries.