> We'll see how it turns out. It may not be feasible to try and generalize > this to all WSGI applications, in which case, too bad, we won't do it. But > I don't think that it will add too much in this particular case.
Sounds like a good approach to me. Ideally we want to attract contributors outside of the TG2 world, and we want to make this something that people want to contribute too (so that we can get OpenID support, ect). This is more likely to happen if we make it work with the tools they allready use. But, TurboGears defines one of the most popular toolsets in the python community, so even if it's TG specific it should attract people. Here's my basic thoughts on the subject off framework independent components: The trade-off between generality and framework specificness should be handled on a case by case basis, depending on who might end up wanting to use it, how much work it is to make it framework independent, and how willing the authors of the component are to work to support non TG2 users. So, we definitely don't want our own ORM, or template system, and we probably don't need our own authentication middleware, but I'd doubt that a user-registration module would be worth making framework neutral, since it will have to have templates, depend directly on the ORM, and it would be very hard indeed to abstract all of that away. And I doubt that the component would really grown non TG2 users. So, it's all something that we have to deal with for each component we create. --Mark Ramm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears Trunk" 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/turbogears-trunk?hl=en -~----------~----~----~----~------~----~------~--~---
