SQLite and other things [was Re: svn commit: r290569]

["Gregory (Grisha) Trubetskoy" <gr...@apache.org>]

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

Re: SQLite and other things [was Re: svn commit: r290569]

[Robert Sanderson <az...@liverpool.ac.uk>]

>So based on the above, I think SQLite support should be removed.

Not that I've done much apart from follow things (and suggest the
revision of how the connection is read) but I agree with Grisha on this
part.

>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.

On the other hand, *quality* contributed code IMO could be distributed
but not 'supported' (for what little distinction there is).  At the very
least it gives people something to base their own code on, rather than
trying to develop in a vacuum or doing time consuming web searches.

-- Rob

Re: SQLite and other things [was Re: svn commit: r290569]

[Jim Gallacher <jg...@sympatico.ca>]

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: testhandler.py [was SQLite and other things ]

[Jim Gallacher <jg...@sympatico.ca>]

Nick wrote:
> Jim Gallacher wrote:
>  > Nicolas Lehuen wrote:
>  >> I thought that all this mptest.py thing was a bit disturbing, as
>  >> usually people took the wrong impression that they had to call the
>  >> /test/mptest.py URL, that is they thought that the handler system was
>  >> a bit like the publisher system. So by providing a test handler in the
>  >> box, we could make sure that the installation was correct without
>  >> having to cope with all the fuss about where mptest.py should be
>  >> located and what URL to use to make sure everything is working.
>  >
>  > I think this is a worthwhile addition as it should make it easier to get
>  > new people started with mod_python.
> 
> Looking at this file, it's a great way to verify that mod_python is 
> working correctly, and it's pretty thorough in checking the apache 
> internals. However, it's neither simple nor intuitive for new people to 
> get started with mod_python I think.  For a newbie, it looks like it 
> could be overwhelming.
> 

Allow me to rephrase. It is a worth while addition as it should make it 
easier *for experienced users* to assist newbies having problems getting 
started with mod_python. :)

Regards,
Jim

Re: SQLite and other things [was Re: svn commit: r290569]

[Nick <ni...@dd.revealed.net>]

Jim Gallacher wrote:
 > Nicolas Lehuen wrote:
 >> I thought that all this mptest.py thing was a bit disturbing, as
 >> usually people took the wrong impression that they had to call the
 >> /test/mptest.py URL, that is they thought that the handler system was
 >> a bit like the publisher system. So by providing a test handler in the
 >> box, we could make sure that the installation was correct without
 >> having to cope with all the fuss about where mptest.py should be
 >> located and what URL to use to make sure everything is working.
 >
 > I think this is a worthwhile addition as it should make it easier to get
 > new people started with mod_python.

Looking at this file, it's a great way to verify that mod_python is working 
correctly, and it's pretty thorough in checking the apache internals. 
However, it's neither simple nor intuitive for new people to get started 
with mod_python I think.  For a newbie, it looks like it could be overwhelming.

Nick

Re: SQLite and other things [was Re: svn commit: r290569]

[Jim Gallacher <jg...@sympatico.ca>]

Nicolas Lehuen wrote:
> 2005/9/24, Gregory (Grisha) Trubetskoy <grisha@apache.org 
> <ma...@apache.org>>:
> 
> 
> 
>     On Sat, 24 Sep 2005, Nicolas Lehuen wrote:
> 
>      > Maybe we should distribute the publisher as an extension module ?
>     Alongside
>      > with Vampire, Django, and other high-level frameworks ?
> 
>     I'd leave the publisher where it is. Mod_python needs at least one
>     handler
>     to demonstrate how it works and provide a quick and easy way to get
>     started, and that handler better not be cgihandler. This is why I think
>     the publisher should be primitive and any of its shortcomings are OK,
>     becuase if you need something fancy - you can use Vampire, etc.
> 
>     I did not notice there was a testhandler.py there. In general we do way
>     too much committing and too little discussion, I'd like to see this
>     ratio
>     reversed. Can we get a little thread on what the testhandler is
>     (sorry if
>     this was discussed and I wasn't paying attention).
> 
>     Grisha
> 
> 
> That's another of my commit :). The purpose of the testhandler was to 
> provide an handler "in the box" so that people could test the Apache 
> side of their configuration without having to write an handler.
> 
> I thought that all this mptest.py thing was a bit disturbing, as usually 
> people took the wrong impression that they had to call the 
> /test/mptest.py URL, that is they thought that the handler system was a 
> bit like the publisher system. So by providing a test handler in the 
> box, we could make sure that the installation was correct without having 
> to cope with all the fuss about where mptest.py should be located and 
> what URL to use to make sure everything is working.

I think this is a worthwhile addition as it should make it easier to get
new people started with mod_python.

Jim

Re: SQLite and other things [was Re: svn commit: r290569]

[Nicolas Lehuen <ni...@gmail.com>]

2005/9/24, Gregory (Grisha) Trubetskoy <gr...@apache.org>:
>
>
>
> On Sat, 24 Sep 2005, Nicolas Lehuen wrote:
>
> > Maybe we should distribute the publisher as an extension module ?
> Alongside
> > with Vampire, Django, and other high-level frameworks ?
>
> I'd leave the publisher where it is. Mod_python needs at least one handler
> to demonstrate how it works and provide a quick and easy way to get
> started, and that handler better not be cgihandler. This is why I think
> the publisher should be primitive and any of its shortcomings are OK,
> becuase if you need something fancy - you can use Vampire, etc.
>
> I did not notice there was a testhandler.py there. In general we do way
> too much committing and too little discussion, I'd like to see this ratio
> reversed. Can we get a little thread on what the testhandler is (sorry if
> this was discussed and I wasn't paying attention).
>
> Grisha
>

That's another of my commit :). The purpose of the testhandler was to
provide an handler "in the box" so that people could test the Apache side of
their configuration without having to write an handler.

I thought that all this mptest.py thing was a bit disturbing, as usually
people took the wrong impression that they had to call the /test/mptest.py
URL, that is they thought that the handler system was a bit like the
publisher system. So by providing a test handler in the box, we could make
sure that the installation was correct without having to cope with all the
fuss about where mptest.py should be located and what URL to use to make
sure everything is working.

Regards,
Nicolas

Re: SQLite and other things [was Re: svn commit: r290569]

[Jorey Bump <li...@joreybump.com>]

Nick wrote:

> 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.

I agree, and my usage is the exact opposite of Nick's. I use mod_python 
exclusively with Publisher, and even I think it's odd to include it. 
With a stable base distribution and a repository of supported handlers, 
it may not be necessary to touch the core if you're simply trying to 
address an issue in a handler.

> 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?).

It also gives handler writers an incentive to contribute code to the 
core without having to study the impact on other handlers included in 
the main distribution. If it raises issues, handler maintainers will 
have an opportunity to voice their concerns or adapt.

Re: SQLite and other things [was Re: svn commit: r290569]

[Jim Gallacher <jg...@sympatico.ca>]

Nicolas Lehuen wrote:
> OK, I agree to remove SQLiteSession. I'll put it on my own website for 
> curious people to use it if they want.
> 
> However, this means that the PythonOption session must be extended for 
> third-party developers to be able to provide their own session 
> implementation.

I want this feature added for 3.3 anyway.

Jim

> Regards,
> Nicolas
> 
> 2005/9/23, Nick <nick@dd.revealed.net <ma...@dd.revealed.net>>:
> 
>     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
> 
> 

Re: SQLite and other things [was Re: svn commit: r290569]

[Nicolas Lehuen <ni...@gmail.com>]

OK, I agree to remove SQLiteSession. I'll put it on my own website for
curious people to use it if they want.

However, this means that the PythonOption session must be extended for
third-party developers to be able to provide their own session
implementation.

Regards,
Nicolas

2005/9/23, Nick <ni...@dd.revealed.net>:
>
> 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
>

Re: SQLite and other things [was Re: svn commit: r290569]

["Gregory (Grisha) Trubetskoy" <gr...@apache.org>]

On Sat, 24 Sep 2005, Nicolas Lehuen wrote:

> Maybe we should distribute the publisher as an extension module ? Alongside
> with Vampire, Django, and other high-level frameworks ?

I'd leave the publisher where it is. Mod_python needs at least one handler 
to demonstrate how it works and provide a quick and easy way to get 
started, and that handler better not be cgihandler. This is why I think 
the publisher should be primitive and any of its shortcomings are OK, 
becuase if you need something fancy - you can use Vampire, etc.

I did not notice there was a testhandler.py there. In general we do way 
too much committing and too little discussion, I'd like to see this ratio 
reversed. Can we get a little thread on what the testhandler is (sorry if 
this was discussed and I wasn't paying attention).

Grisha

Re: SQLite and other things [was Re: svn commit: r290569]

[Nicolas Lehuen <ni...@gmail.com>]

2005/9/23, Nick <ni...@dd.revealed.net>:
>
> 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
>

Note that a review of the import system is needed even if we excluded the
publisher from the core distribution. mod_python needs to dynamically import
its handlers and the current way it is done is somewhere between error prone
and bugged.

Maybe we should distribute the publisher as an extension module ? Alongside
with Vampire, Django, and other high-level frameworks ?

Regards,
Nicolas

Re: SQLite and other things [was Re: svn commit: r290569]

[Nick <ni...@dd.revealed.net>]

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