Graham Dumpleton wrote: > On Aug 26, 6:55 pm, Alvaro Lopez Ortega <[EMAIL PROTECTED]> wrote: > >> There is a bunch of examples and similes that support this affirmation. >> Well known and accepted programming paradigms, the Unix way of working: >> applications with a single purpose communicating with each other (never >> embedding), or even the current web technology where people keep their >> data, formating (css) and application logic independent for the shake of >> maintainability. > > All well and good, but in practice the majority of people will not > care about that one bit. People just want something that works and > even if it could be argued that the way something is internally > implemented may not be pure in one sense or another, that will nearly > never come into it. Give them something that, at the level they want > to work, is easy to use and has the features they need, they will be > more than happy.
Sounds pretty much as if you were talking about Windows. ;) It is my believe though that we (F/OSS guys) usually run the extra mile and do 'the right thing'. Users will be at least as happy as with less technically correct solution, and it will pay us off in the medium term. >> So, despite what you suggest, if a bare minimum interpreter is twice as >> big as the web server, I wouldn't personally call it "small". IMO Python >> rocks anyway, but calling it small may be too much. > > But to put that if further context, it is not uncommon for a process > holding a Python web framework instance to be anywhere between 40 and > 100MB for a typical site. You have just raised my point. You do NOT want your web server process to weight 100Mb if it can weight 1.3Mb! It might be my perception, but having such a big web server in memory without a really REALLY good reason sounds mad. And the point is that there is not such good reason but a few problems. Having Python plus the application logic executing under another PID is much cleaner form the architectural point of view, and as a matter of fact, more secure. For instance, if the interpreter crashes because a bug in one of the dozens of libraries that it needs to load, I want my web server to continue serving cached and static content until a new application server is spawned and ready to use. What would happen if the interpreter called a blocking third party function? Depending on the web server architecture it would either starve or trigger a -let's call it- emergency mechanism to take care of the situation (which does not sound clean nor reliable at all). Besides, running the same WSGI application as a SCGI app-server would, in the worst scenario, be as fast as running it in the embedded interpreter (in fact, I bet it is faster). So, I still understand that there is a basic issue in the model. There is no clear win for the couple of problems that are introduced (security and architecture). >> Anyway! Let's put the swords down. > > Oh, but technical discussions like this are always fun. It wasn't > really meant as an attack in the first place, but more of a sharing of > information. :-) Of course it was figure of speech! I'm glad you came by! :-) -- Greetings, alo http://www.alobbs.com/ _______________________________________________ Cherokee mailing list [email protected] http://lists.octality.com/listinfo/cherokee
