Huy said: > always the easiest thing to do anyway. The business logic has always > been the main challenge in all the applications I've been involved with > regardless of language or platform. > I would agree here. The lion's share of work is always in actually using the tools. Judicious time spent improving the tools can help significantly, but at some point you have to put on the "I've got to get this thing done regardless of how elegant it is" hat and get to work on what really matters to the client.
> My only advice is, ff you don't know what it's used for, don't use it. > That would go for anything really. If you can't think of why SQLObject > should not be used instead of MiddleKit then just use SQLObject. You > guys need to make certain decisions on your own. All the information is > out there to make your own judgements. > I agree. One of the things I like about Webware is that it doesn't (for the most part) *force* you to use tool A because you are using tool B, unlike some other Python frameworks (cough...cough...Zope). On the other hand, it would be nice if those who are using the various tools contributed their knowledge back to the community in a more formalized and organized fashion than just posts to the mailing list (wiki anyone ?). However, I can't be too critical because I am just as guilty as the next person. > complaining. Ohh and by the way, whoever said CGI was not scaleable was > talking out of their ass. > I'm not sure if this was directed at me or not. If so, I didn't mean to imply that CGI was not scalable. In fact, we have found that CGI is VERY scalable. Just throw enough hardware at the application and it will scale almost infinitely. That is why we have 13 (albeit small) machines serving one application. The problem we have is request latency. Under the CGI model, we have to be very careful about how much code we are loading on each request. We also have to be very careful to reuse database connections where possible. The code-loading issue leads us to do performance optimization in the form of lazy definition of constants, etc. These optimizations make the code more complicated and less clear than it would be if we had a long-running process that could load the code once and then just *have it* in memory. The database connection reuse issue has been solved by using a pooling mechanizm similar to the DbConnectionPool module that I open-sourced. Still, we have to incure the overhead, on each request, of building the database connection for each database we need to talk to. This overhead can be significant for IBM DB2, which is the database that corporate says we *must* use. Even with our best efforts so far, our request latency is still to high in my opinion. There are more things that we could still do, but the powers-that-be have decided that it is currently "good enough", given our planned move to J2EE. -- Warren Smith [EMAIL PROTECTED] ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Webware-discuss mailing list Webware-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-discuss
