on Mon Jan 12 2009, Jeff Hammel <jhammel-AT-openplans.org> wrote:
> I was under the assumption that the important part was to avoid the > runaway processes. But yeah, the webserver or middleware can't > magically know about trac's internals (or really shouldn't, in any > case). > >> > or middleware, >> >> I've never really understood that term, so can't comment. >> >> > though a plugin would be trivial to implement (IRequestFilter). >> >> Is this a case of "it can be implemented in a plugin, so it should be?" > > Probably? Well, yes. I make little differentiation philosophically > between components that come with core and components packaged in > plugins. To me this seems like an(other) example of something that everybody will eventually want, and should be packaged with the core. You already have these weak "max_bytes" and "max_files" limits in the core, so *somebody* clearly thought it was core's business to avoid hanging the server. The problem is that the existing approach is ineffectual. Eventually someone like me who assumes the core settings are reasonable will get bitten, and then there will be a bug report. Again. > But yeah, a plugin seems the right place to put it. Why, please? IMO someone really needs to lay out a set of criteria that distinguish things that should be in core and things that shouldn't. Even if the criteria are slightly fungible, it would be an improvement. -- Dave Abrahams BoostPro Computing http://www.boostpro.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en -~----------~----~----~----~------~----~------~--~---
