Graham Dumpleton writes:
> Daniel J. Popowich wrote ..
> > PS
> > If it's not obvious I'm gearing up to get way more involved...I've
> > been waiting (patiently) for 3.2 to be released and jump in with new
> > 3.3 development...I guess I'm chomping at the bit...
>
> We probably want to defer until after 3.2.7 (final) is released to have
> any serious discussion about what should constitute version 3.3, but
> am still curious to know at this point where your interests in 3.3 lie.
> Is it simply to help finish up eliminating all these known issues/bugs
> or do you have other ideas in mind as to the direction of mod_python?
As you know I come to mod_python as a platform to develop mpservlets.
I have come to think of mod_python as a tool to write low-level
handlers and higher-level frameworks for re-use. Based on the threads
in the user list I think it's safe to say that most come to mod_python
not to write low-level handlers with a python interface to the apache
C API (beyond the methods and members of the request object, anyway),
but rather to find a pythonic view of the web; most gravitate to
publisher, but I think this is largely because it's what's presented
in the early sections of the manual. I wouldn't be surprised to hear
that most newbies think mod_python and the publisher handler are one
and the same.
But I digress...
These are the issues that interest me. I'm aware that many have
already been discussed by you and others. In no particular order:
o A grand unified module caching scheme that can be used by all
handlers (psp, publisher, mpservlets, vampire, etc.) with an API
flexible enough to meet many if not all needs. Independent
versions of such were developed for psp and mpservlets and Vampire
(and there's something new for publisher in 3.2?). Let's get one
in a well-defined interface.
o Tightly coupled with the previous item: clearing up what it means
to import modules in embedded python and the whole crap around the
PythonPath directive. In a nutshell: how to stop the daily
questions on the user's list about importing, sys.path and the
cwd. (I have radical ideas on this, btw.)
o _apache._global_lock(). I would like to see a higher-level
interface for framework developers to make use of this feature. I
can now, sure, but without mod_python publishing a contract
(mod_python uses this...you can use that...) with downstream
framework developers, enforced by an API, it's hard to know what I
can or should do.
o Higher-level calls to help determine the environment mod_python is
running in. Think MPMs. I would like to work on an Application
Management abstraction in mpservlets, but it's difficult to do
right now without pain.
o This may be hard to stomach (and it's not a super high priority
item on my list), but the whole Field/FieldStorage classes have
never worked for me. I understand why they're there, or at least
I think I do: familiarity with the cgi module. Way too painful
for me to use directly which is why I wrote the
query_vars/form_vars for mpservlets.
o This marathon of a thread
http://thread.gmane.org/gmane.comp.apache.mod-python.devel/1922
should be explored. Is there something we can do to help clear up
URL parsing issues?
o And...no suprise...I'd like to try to sell mpservlets for
inclusion in the main distro. No tears if it's not, but I think
it fills a void and I'd like to make a case for its inclusion.
Enough already.
Daniel Popowich
---------------
http://home.comcast.net/~d.popowich/mpservlets/
