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
Attachment:
pgp6fXbLAiWaB.pgp
Description: PGP signature
_______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
