CherryPy 2.1 has been released

[Kevin Dangoor]

FYI, CherryPy 2.1 final has been released:
http://sourceforge.net/project/showfiles.php?group_id=56099

Kevin

--
Kevin Dangoor
Author of the Zesty News RSS newsreader

email: k...@blazingthings.com
company: http://www.BlazingThings.com
blog: http://www.BlueSkyOnMars.com

[Todd Greenwood]

One of the things I'm looking at atm is the session management in
CP2.1. Looks great. One question, though. It looks like the session
backends it comes with are ram,file, and postgresql. While these are
all great options, why not just use SQLObject as the abstraction layer,
instead of requiring the consumer to write a custom backend if they
want to use a different database, etc?

Perhaps this is part of a larger question. TG is an aggregator of other
technologies, and the underlying components may not share the same
overall philosophy as this project. For example, here it seems that CP
doesn't share the same abstraction of SQLObject as the data store.

Does this mean that TG is going to own abstracting the session backend?
Or is this one of those grey areas where the community will have to
fend for itself?

http://www.cherrypy.org/trunk/docs/book/chunk/ch03.html#id2940947

[John Speno]

On Oct 21, 2005, at 3:01 PM, Kevin Dangoor wrote:

>
> FYI, CherryPy 2.1 final has been released:
> http://sourceforge.net/project/showfiles.php?group_id=56099

And a warning that it no longer comes with the VirtualHostFilter
which some people have talked about here.

It was broken and fixing it was deferred to CherrryPy 2.2.

http://www.cherrypy.org/ticket/344

[Kevin Dangoor]

On 10/21/05, Todd Greenwood <t.green...@gmail.com> wrote:
>
> One of the things I'm looking at atm is the session management in
> CP2.1. Looks great. One question, though. It looks like the session
> backends it comes with are ram,file, and postgresql. While these are
> all great options, why not just use SQLObject as the abstraction layer,
> instead of requiring the consumer to write a custom backend if they
> want to use a different database, etc?

Actually, if you look at this page:
http://www.cherrypy.org/wiki/SessionFilter

you'll see that someone started an SQLObject backend but didn't finish
it. There was a ticket opened that said that there was some complexity
involved:
http://www.cherrypy.org/ticket/220

> Perhaps this is part of a larger question. TG is an aggregator of other
> technologies, and the underlying components may not share the same
> overall philosophy as this project. For example, here it seems that CP
> doesn't share the same abstraction of SQLObject as the data store.

My philosophy is that we do what we need to do to get the
functionality we need to have. Under ideal, and likely, circumstances
we'll get the functionality rolled into the other projects and keep
TurboGears itself pretty slim. We get to leverage a much larger
community that way.

But, any code that is specific to the combination of tools we have,
we'll likely just have to own it in this project.

In short: build the features we need, possibly starting their life in
TurboGears, but move those features into the core projects as much as
possible.

> Does this mean that TG is going to own abstracting the session backend?
> Or is this one of those grey areas where the community will have to
> fend for itself?

Maybe the thing to do here is to open a ticket in our Trac that
references the CherryPy ticket, since we're the ones most likely to
care about such a thing.

[Kevin Dangoor]

That's right... I remember Fumanchu mentioning that on IRC yesterday.
Thanks for bringing it up.

[Todd Greenwood]

Looks a bit sticky. As mikerobi has stated that it's a wontfix due to
complexity and that 'sqlobject is not 100% thread safe'. Perhaps we
should get the SQLObject folks to talk to the CP folks?

-Todd

Mon 22 Aug 2005 03:25:22 PM CDT: Modified by mikerobi

* resolution set to wontfix
* status changed from assigned to closed

An sqlobject adaptor requires uneccessary complexity do to convertion
to and from python dictionarys. The sqlobject adaptor has been dropped.
A driver based on PyDO2 will take its place. (I am not against
including an sqlobject adaptor if someone else would like to contribute
it, but I suggesting waiting till after I release the PyDO adaptor, so
you can see how column names are handled.)

[Kevin Dangoor]

That's odd. SQLObject is threadsafe.

It's possible that he was using SQLObject 0.6.1, which was the current
stable version at the time. SQLObject 0.7 had quite a bit of work done
on it, so it's entirely possible that it's easier today than it was
then.

Kevin