Turbogears downgraded on fas servers

[Toshio Kuratomi]

On Sun, Jan 09, 2011 at 09:24:37PM +0100, Athmane Madjoudj wrote:
> On 01/09/2011 08:04 PM, seth vidal wrote:
> > On Sun, 2011-01-09 at 10:21 -0800, Toshio Kuratomi wrote:
> >
> >...
> >
> > I would be willing to wager the delay in porting is the same delay in
> > porting anything - it just sucks to rewrite code you wrote before and
> > sift around new details of the new system.
> >
> > It's just not fun.
> 
> What about using "homemade" stacks without mega-framework ie:
> 
> CherryPy + SQLObject or SQLAlchemy + Kid or Cheetah ...etc
> 
> Will this cost much effort ?
> 
I would say yes.  TurboGears1.0 and 1.1 are basically CherryPy2 + (SQLObject
or SQLAlchemy) + (Kid or genshi).

TurboGears-1.5 is CherryPy3 + SQLAlchemy + genshi.

TurboGears2 is Pylons + SQLAlchemy + genshi

By building on top of TG we get a little bit of abstraction from the
underlying layers (for instance, we could go with kid on all of those
frameworks even though it's not the default.  Same with SQLObject, at least
for the TG-1.x's).  We also get some niceties (like setup of some of the
components done for us).

If we built out own framework on top of the same underlying components
I think we'd just end up reinventing a lot of TurboGears code and still
having to deal with upstream version change... just at the level of
upgrading from CherryPy2 to CherryPy3 or kid to genshi instead of at the
level of TurboGears.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/infrastructure/attachments/20110109/21f9e8e0/attachment.bin