On Mon, Jan 12, 2009 at 07:46:59PM -0500, David Abrahams wrote: > > > 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.
I can't argue with that, but... > > 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. Two points: * releases for trac are triaged well ahead of time. For instance, the 0.12 release focuses on i18n (IIRC). So even if this additional feature was trivial (which it almost is), it might not be slated until several releases in the future. Read: several years (maybe). I'm all for faster development of trac. That being said, I haven't thrown my hat in the ring to this end, so I can't complain. But plugins can be developed and version completely independently and can provide a solution for everyone (that follows trac-hacks, anyway) now. ...relatedly... * developing components as plugins allows for independent efforts of implementation, testing, and release from core. You can work out a solution without having to tramp all over a shared code base. Once a plugin has been proven, it is much easier to propose an enhancement to core and really start to answer the question: "do people want this?" You can actually see what the plugin does and meaningfully judge it. That's my opinion anyway, as a plugin and non-core developer. One of my patches is now in core (from the AutoQueryPlugin) and another is triaged for 0.13 IIRC (from the AutocompleteUsersPlugin). On the other hand, if you wanted to provide a patch, I'm sure that would be considered too. Jeff Hammel IRC: jhammel, k0s --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
