Re: SQLite and other things [was Re: svn commit: r290569]
Gregory (Grisha) Trubetskoy wrote: Just to put this SQLite business to rest. I think that (and we can discuss this - I don't set laws, I just have opinions that may not always beright, so feel free to comment) mod_python should do fewer things but do them exceptionally well. Roughly speaking, to be included in mod_python something has to fall into the category of Apache/Python integration or demonstrate to be addressing a challenge introduced by the mod_python environment and too difficult to address by an average (Python) programmer. Given this definition, the reason Sessions were included was that it turned out that implementing session support under mod_python was not a trivial task and required use of APR locking (which was implemented for Sessions IIRC). Similar reasoning behind the inclusion of PSP - it's not something an average Python programmer could whip up, but it is also a bit of a stretch and its inclusion was (and is) controversial. Cookies were included because the standard Python lib module assumed a CGI environment and was (and is) IMHO lacking in many ways. On a more practical note - interoperation with third-party applications creates a dependency. So even though SQLite would not have to be installed in order for mod_python to work, it _would_ have to be installed in order for the test suite to run. Or you don't test it, in which case you risk it becoming broken and not noticing it. And if we were to continue down this path, imagine having to have MySQL, PostgreSQL and Oracle installed in order to run the test suite - we'd never get any +1's on the list this way :-) So based on the above, I think SQLite support should be removed. The thing we need to address is what to do with nifty things we create but that don't qualify for inclusion. The idea of a 'contrib' directory has been floated around for a while, I for one am against it for the same reasons above - it should either be 100% supported or not included at all IMO. I think for the time being the best approach is for people to use their own resources to publish contrib-type code on the web and just follow the usual process of announcing it on the list. Grisha Grisha, I think much what you write could be distilled into The mod_python Philosophy and should included in the documenation as such. I'm ambivalent on the subject of a contrib directory. In theory it's a great idea. In practice it often seems that a project's contributed code is out of date and unmaintained. I think we should *only* ship production quality code. This means that we would need to take responsibilty for maintaining contributed code which I think would be a bad idea - our resources are too limited. It may be worthwhile expanding on our example code however. I don't think people expect examples to be full fledged implementations, but can be a great starting point for a user to create their own code. I guess we can still get into dependency problems here as well though. There are no easy answers. Regards, Jim
Re: SQLite and other things [was Re: svn commit: r290569]
Gregory (Grisha) Trubetskoy wrote: I think that (and we can discuss this - I don't set laws, I just have opinions that may not always beright, so feel free to comment) mod_python should do fewer things but do them exceptionally well. I would agree with that totally. As a long time user of mod_python, I would add that I personally disagree with including Sessions, psp, publisher, etc. in the base distribution, since these things seem to have held up releases. I don't use any of those things as all with mod_python, and I don't see how they're necessary to use mod_python for what it's for: creating apache extension modules in Python. The thing we need to address is what to do with nifty things we create but that don't qualify for inclusion. The idea of a 'contrib' directory has been floated around for a while, I for one am against it for the same reasons above - it should either be 100% supported or not included at all IMO. If that's the case, there definitely needs to be a central place for contributed code like this. I think a contrib directory is convenient, but I also know the issues of who decides what to put in there, how much do put include, how do you gently waive off support requests for its contents. But there needs to be something. What do you see on the list all the time? People asking how do I implement database pooling, how to I use sessions, here's my database implementation for sessions. I say put the publisher there as well, since it doesn't have anything to do with the philosophy of mod_python, even by Grisha's definition, and solves some release issues with mod_python itself (can anyone say imports?). Nick
