The Artima Developer Community
Sponsored Link

Weblogs Forum
Web Framework Redux

33 replies on 3 pages. Most recent reply: Mar 7, 2006 8:56 AM by Robin Parmar

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 33 replies on 3 pages [ « | 1 2 3 ]
Guido van van Rossum

Posts: 359
Nickname: guido
Registered: Apr, 2003

Re: Web Framework Redux Posted: Feb 3, 2006 8:03 PM
Reply to this message Reply
Advertisement
> Guido, you've expressed that you want a web library that
> can function in a web-server-neutral manner. I think you
> should reconsider the web-server-neutral part.

>It almost sounds as though you want to write an
> application server in python. But why reinvent the http
> wheel?
[...apache_mod_python recommendation snipped...]

Sory, no go. Google has an internally developed web server. It would be foolish not to plan to use that, but I don't want to tie myself to it exclusively -- it's not a good fit during (early) development.

For develpment, BaseHTTPServer.py makes much more sense, and since it's in the Python standard library, I don't have to reinvent that particular wheel at all!

There are other deployment options too -- Google has several ways to deploy intranet services, and I don't want to make an early decision that ties me into a particular server technology.

Anyway, after reading PEP 333 (WSGI) and downloading Phillip Eby's wsgiref library (which hooks cleanly into BaseHTTPServer.py) I believe I can develop my application without giving much thought to deployment options until much later -- it will always be possible to write a simple WSGI adapter for whatever server technology I end up choosing.

Mike Bonar

Posts: 1
Nickname: glide
Registered: Feb, 2006

Re: Web Framework Redux Posted: Feb 4, 2006 10:42 AM
Reply to this message Reply
Lead the charge, Guido!

I have been wishing for the same thing for the last couple of years. As a web application performance architect and performance automation resource, I have been dreaming of an alternative to what I see customers doing with the J2EE framework and their web apps. I would also like to see and work on an open source web performance testing framework. There's a project called funkload that has started taking steps in this direction, but much work still needs to be done.

Design your framework with performance in mind from the very beginning. Not only does it need to be fast, but it needs to be built so that the components and interfaces can be easily measured for performance.

Keep the momentum going.

Mike Bonar

John Wang

Posts: 1
Nickname: mazr
Registered: Feb, 2006

Re: Web Framework Redux Posted: Feb 21, 2006 9:58 PM
Reply to this message Reply
Thanks for your blog Guido. It confirms a lot of what I've read and suspected about Ruby and Python frameworks, namely that they are great if you wish to build a certain type of application but perhaps not flexible enough to build something unique. I've been interested in trying out TurboGears and Ruby on Rails, however, my current project has specific and custom requirements. These requirements have led me to use the Catalyst framework which is written in Perl. I'm not going to try and convince anyone to use Perl or Catalyst but explain why it's different and why it's approach maybe one that fits your needs better. It's more a difference in philosophy than anything else. Perhaps it can shed a different light on the situation.

Ruby on Rails and similar frameworks offer a "full-stack" approach. They tend to have a solution for everything but only one solution. If you want something else you may be on your own. I've often hear the phrase "The Ruby Way" which tends to discount differing real-world requirements. If your requirements happen to be different, the framework may not be usable at all. Catalyst offers a modular approach to framework building. At it's core there is a flexible url dispatcher and support for multiple HTTP engines (mod_perl, FastCGI, etc.), but it's attractiveness is that it gives you a choice for the items you mentioned: templates, persistence, authentication, sessions, forms, etc. There are many templating systems supported including 3 popular HTML options, XML/XSLT and even PHP. There are several caching options including local memory cache, local file cache, and memcached servers. I recently moved from a local memory cache to memcached servers simply by switching plugins. Session management has the same options including using a database-backed system. There are also multiple ORM choices including 3 popular ones but if a raw database connection is what you need for raw SQL, that's available as well. Perl ORMs can load existing database schemas, handle multiple joins and recognize foreign keys. Some Perl ORMs also include a raw SQL passthrough as an option for occasional use. As much as some would like to think otherwise, there are some SQL queries that cannot be easily abstracted via an ORM. For my current project I need the flexibility of having a choice of pre-built components but creating my own as well. For example, I have use a custom authentication framework.

The difference between Catalyst and other frameworks is, in part, based on the difference between and age of the language communities. Without getting into a debate about which is better or worse, let's just say they are different. In Perl, there is a recommended way but it's not the only way. Without discipline, this can cause issues issues but it has also led to to multiple mature ways of doing things. Before Catalyst, there were already multiple mature Perl templating systems, ORMs, etc., each with their own community joined via CPAN. To support the existing Perl community, Catalyst has to be flexible and modular. I have the impression that other languages don't have as large an existing library with mature competing solutions so it's easier for a framework to be a full-stack.

Sometimes a full-stack is better and other times a more flexible approach is better. It depends on the project requirements. I've recommended full-stack Python and Ruby frameworks when the project fits but when it comes to custom projects, Catalyst lives up to the Perl slogan "making easy things easy and hard things possible." For a creative, custom project, I don't want to take any options/capabilities off the table. As much as I'm interested in the language elegance of Python and Ruby, when it comes to frameworks, Catalyst gives me the flexibility I need. I'm not yet convinced the full-stack frameworks can but perhaps, with this discussion, Python frameworks will become more flexible and a viable option.

Robin Parmar

Posts: 3
Nickname: robin746
Registered: Mar, 2006

Re: Web Framework Redux Posted: Mar 7, 2006 8:56 AM
Reply to this message Reply
Thank you everyone for your informative responses. I am collating my own experiences on my web site, particularly under the Programming category. I've already got four related articles and a conclusion yet to come.

Surf:
http://noisetheatre.blogspot.com/2005/07/category-programming.html

Flat View: This topic has 33 replies on 3 pages [ « | 1  2  3 ]
Topic: The Backside of an Interface Previous Topic   Next Topic Topic: Too Much Fun with Python on Nokia Phone

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use