| Gregory (Grisha) Trubetskoy 2005-09-22, 8:47 pm |
|
On Thu, 22 Sep 2005, Jim Gallacher wrote:
> Gregory (Grisha) Trubetskoy wrote:
>
> Yes. ;)
And how did we arrive at this decision? :-)
I'd be pretty strongly -1 on this, as it's got little to do with
Apache/Python integration which is our core mission.
I think it might be interesting to see something like an ANSI SQL-92
compatible session with some suggestions on how it can be easily
integrated with your database vendor of choice, but deifinitely not
support specific database vendors, except for those whose support exists
natively in the Python distribution (which is none at this point).
....so nothing unique about sqlite? If so, I don't think it should be part
of mod_python unless/until it is standard in Python, then we can discuss
it.
[vbcol=seagreen]
> I don't know if it is that path we *want* to take, but I think there is a
> certain inevitability that it's the path we *will* take.
We will take the path we want :-)
> I'm personally thinking about a mysql backend, not because I need it but
> because I'm curious to compare the performance with FileSession.
But does this mean it has to be included in mod_python?
> The best approach might be to refactor Session.py to easily accommodate
> subclasses for other persistent stores.
That I can agree with. Not necessarily "Session.py" but rather the Session
class (inside Session.py). I remember that a lot of time/thought went into
it, so it's not like it's going to be a "no-brainer" though.
> Any new session subclasses get their own file eg.
>
> mod_python/sessions/sqlite.py
-1
> mod_python/sessions/mysql.py
-1
> The current Session.py could stay as is, or we could split FileSession,
> DbmSession and MemorySession into their own files
I think at this point it'd be cleaner to move the FileSession class into
the Session.py file rather than split into individual files. I'm not sure.
Something to ponder upon, I guess.
> and just have a stub in Session.py for backward compatability.
Not "backwards compatibility", but "default". Using Session should let you
use the session mechanism that is most recommended if you do not want to
think about it too much.
> On another note, if we are starting to roll with new features for 3.3 I would
> suggest we need to immediately create a new svn branch for 3.2 bugfixes.
Yes
Cheers,
Grisha
|