Any plan toward CherryPy 3?
gas...@gmail.com
At least I know CP3 has 3 times faster performance than CP2, wsgi,
python 2.5 support, better looking error pages, and
RoutesDispatcher(found in trac).
So is there a timeline or roughly plan to support CP3?
ex: it will be dealed during January 14-16(TurboGears Jam)?
Will the migration cause TG API change?
--
Fred
Mikkel Høgh
CherryPy will necessitate some changes - Python projects aren't (and
should not be) known for their API stability, but i reckon it should
not be that bad. TurboGears is well engineered.
--
Regards,
Mikkel Høgh
Karl Guertin
> So is there a timeline or roughly plan to support CP3?
> ex: it will be dealed during January 14-16(TurboGears Jam)?
>
> Will the migration cause TG API change?
My understanding is that CP3 will come with the 1.1 release and won't
be part of the 1.0 line. I anticipate a number of changes in the
config files in order to get apps working, but don't see really large
changes otherwise. At least I hope not.
Kevin has talked about migrating to CP3 and Genshi as the default
components in their categories but I believe the rest is remaining
as-is.
Major areas for potential change within the TG code base are identity
and the toolbox. I believe that widgets are fairly stable now and
haven't heard about any large feature additions. I expect most of the
additions will take the form of plugins available via cogbin or from
the rest of the wsgi stack. I know one of the goals for the project is
to break the current code base out into reusable pieces.
If anybody knows better, I'd like to hear it.
Kevin Dangoor
>
> On 10/12/06, gas...@gmail.com <gas...@gmail.com> wrote:
>> So is there a timeline or roughly plan to support CP3?
>> ex: it will be dealed during January 14-16(TurboGears Jam)?
>>
>> Will the migration cause TG API change?
>
> My understanding is that CP3 will come with the 1.1 release and won't
> be part of the 1.0 line. I anticipate a number of changes in the
> config files in order to get apps working, but don't see really large
> changes otherwise. At least I hope not.
Unless you use cherrypy features directly yourself, like filters and
such, I doubt there'd be much difference for a TG app... but I won't
know for sure until I try CP3 myself!
Either way, I would certainly expect to ship the next major version
of TG with CP3.
Kevin
Mark Ramm
> > be part of the 1.0 line.
> > I anticipate a number of changes in the
> > config files in order to get apps working, but don't see really large
> > changes otherwise. At least I hope not.
If somebody is adventurous enought to try to make this work (not me
this week, but hopefully soon), here's a link to the changes that
might need to be made:
http://www.cherrypy.org/wiki/UpgradeTo30
It even looks like there's a function that will parse your config
options and let you know of any names that need to change.
If only we had a few more hours in the day.
--Mark
gas...@gmail.com
I did the CP3 "port" with minimum set of "start_server", "controllers",
"expose", "url", "redirect" and "config" functions, (see the
attachment)
You could run the quickstart project without modify any code in it.
http://trac.turbogears.org/turbogears/ticket/1181
You see it's function are back to early stage of TurboGears and It
didn't handle the template, database....,etc. I just found this way is
easier than porting CP3 to trunk though.
BTW I'd like to mention that some issues are not that easy to solve in
trunk, such as genshi porting for toolbox and widget. Or decouple
SQLObject/SQLAlchemy bonding issues. And to assemble the required
components to this "CP3 core" is not that hard.
I am tracing the thick "expose" function now, which aggregate many
functions and deprecate params. Maybe someone is adequate to make this
"CP3 core" full functional with decorators.
--
Fred
Kevin Dangoor
On Nov 22, 2006, at 10:27 AM, gas...@gmail.com wrote:
> I did the CP3 "port" with minimum set of "start_server",
> "controllers",
> "expose", "url", "redirect" and "config" functions, (see the
> attachment)
> You could run the quickstart project without modify any code in it.
>
> http://trac.turbogears.org/turbogears/ticket/1181
>
>
> You see it's function are back to early stage of TurboGears and It
> didn't handle the template, database....,etc. I just found this way is
> easier than porting CP3 to trunk though.
>
> BTW I'd like to mention that some issues are not that easy to solve in
> trunk, such as genshi porting for toolbox and widget. Or decouple
> SQLObject/SQLAlchemy bonding issues. And to assemble the required
> components to this "CP3 core" is not that hard.
How is Genshi porting not easy to solve? Seriously, I think we just
replace Kid with Genshi and fix up the breakage. "sitetemplate" will
likely disappear.
I'm not sure which SQLObject/SQLAlchemy bonding issues you're
referring to...
> I am tracing the thick "expose" function now, which aggregate many
> functions and deprecate params. Maybe someone is adequate to make this
> "CP3 core" full functional with decorators.
Unless CP3 has changed the way its expose works dramatically, I would
think that TG's decorators would continue to work as-is.
That said, the decorators are the part of TG that needs the most
work. The idea will be to simplify them dramatically by moving most
of the actual "decoration" out so that the decorators themselves
really just register behaviors for a given method. Part of what makes
our decorators so complex is that they try to maintain method
signatures and such even while multiple decorators are stacked one on
top of the other. If we can eliminate all of that, I think we'll be
much happier.
Kevin
gas...@gmail.com
Kevin Dangoor 寫道：
> How is Genshi porting not easy to solve? Seriously, I think we just
> replace Kid with Genshi and fix up the breakage. "sitetemplate" will
> likely disappear.
While I monkey-ported toolbox to genshi, most parts are ok but Catwalk
didn't work properly. It may caused by Datagrid widget dependency or
the template.
--
Fred
Jorge Vargas
Catwalk is too couple with both kid and SO, IMO it's better to do a
rewrite specially because of the fact that the original author is no
longer around
>
> --
> Fred
>
>
> >
>
fumanchu
> That said, the decorators are the part of TG that needs the most
> work. The idea will be to simplify them dramatically by moving most
> of the actual "decoration" out so that the decorators themselves
> really just register behaviors for a given method. Part of what makes
> our decorators so complex is that they try to maintain method
> signatures and such even while multiple decorators are stacked one on
> top of the other. If we can eliminate all of that, I think we'll be
> much happier.
Yes, you will. :) Feel free to re-use _cp_config, which is how we did
the same thing for CP 3.
Robert Brewer
System Architect
Amor Ministries
fuma...@amor.org
Kevin Dangoor
That's right... I forgot that you had already solved our problems for
us :)
Kevin
Kevin Dangoor
I'm very keen on seeing FastData overtake Catwalk anyhow.
kevin