mod_php vs mod_python - php

Why mod_python is oop but mod_php is not ?
Example :We go to www.example.com/dir1/dir2
if you use mod_python apache opens www/dir1.py and calls dir2 method
but if you use php module apache opens www/dir1/dir2/index.php

Let's talk about mod_python vs. mod_php.
Since the Python language is NOT specifically designed for serving web pages, mod_python must do some additional work.
Since the PHP language IS specifically designed to serve web pages, mod_php simply starts a named PHP module.
In the case of mod_python (different from mod_fastcgi or mod_wsgi), the designer of mod_python decided that the best way to invoke Python is to call a method of an object defined in a module. Hopefully, that method of that object will write the headers and web page content to stdout.
In the case of mod_wsgi, the designer decided that the best way to invoke Python is to call a function (or callable object) in a module. Hopefully that function will use the supplied object to create header and return a list strings with the web page content.
In the case of mod_php, they just invoke the module because PHP modules are designed to serve web pages. The program runs and the result of that run is a page of content; usually HTML.
The reason mod_php works one way, mod_python works another and mod_wsgi works a third way is because they're different. Written by different people with different definitions of the way to produce a web page.
The php page can be object-oriented. A mod_wsgi function may be a callable object or it may be a simplef unction. Those are design choices.
The mod_python requirement for a class is a design choice made by the designer of mod_python.
The reason "why" is never useful. The reason "why" is because someone decided to design it that way.

Because mod_python is abstracting the URL into a "RPC-like" mechanism. You can achieve the same in PHP. I always did it by hand, but I am pretty sure there are prepackaged pear modules for this.
Note the mod_python behavior is not forcibly "the best". It all amounts to the type of design you want to give to your application, and how it behaves to the clients. As far as I see, the mod_python approach assumes that for every URL you have a function, like mapping the module structure into a URL tree. This is technically not a particularly nice approach, because there's a tight correlation between the technology you are using (mod_python) and the URL layout of your application.
On the reason why, theres' no reason. Some people like one food, and some other like another. Design is, in some cases, a matter of taste and artistic choices, not only technical restrains.

I think you have some misconceptions about how HTTP works. Nothing in the http standard requires you to have a certain file as a resource. It is just the way how mod_php works, that for a given path, this path is translated to a php file on the disk of the server, which in turn is interpreted by the compiler.
The mod_python module on the other hand is much more generic, it allows you to map any resource to a call to some python object. It just happens that some configurations are available out of the box, to make it easier to start with. In most cases the dispatch of the url is managed by your framework, and how that works is up to the framework implementor.
Because of the generic nature of the mod_python module you are also able to access some apache features which are not available in the mod_php module, for instance you may write your own authentication handler, which my not only apply to your python webapp, but also to other apps in your apache as well.

in PHP you can program your web pages the top-to-bottom scripts, procedural programming and function calls, OOP. this is the main reason why PHP was first created, and how it evolved. mod_php is just a module for web servers to utilize PHP as a preprocessor. so it just passes HTTP information and the PHP script to PHP interpreter.
the PHP way of web page creation is do what you want; write a top-to-bottom script, define functions in different files and include those and call functions, or write your app in OOP, you can also use many full-featured frameworks today to make sure your application design and structure meets today best practices and design patterns.
I'm new to Python, and am not familiar with web programming with python. but as much as I know, python was not created to make web programming easier. it was intended to be a general purpose programming language, so although it might be possible to write simple top-to-bottom scripts in python and run them as web page responses (I'm not sure if such thing is possible), it is not the pythonic way, and so I think developers of the mod_python wanted web programming in python to be in a pythonic way.

Perhaps I misunderstand your question, but both Python and PHP support both procedural and object-oriented programming. (Though one could argue that Python's support for OO is the stronger of the two.)

See Class and Objects in PHP 5

Related

Haskell web applications using PHP as a "front end"

There have been great things happening in the Haskell web development world, and some of the available frameworks (Yesod and Snap server) seem quite mature. However the learning curve can be a bit steep, and perhaps building web apps cannot quite be considered Haskell's forte.
The answer to another SO question of mine indicates that writing PHP extensions in Haskell should be possible. Infact I'm currently in the process of trying to convert a small Haskell program to a PHP extension as a proof of concept.
So, the question is - is there a case for creating a Haskell web framework that is meant to be run as a PHP extension and leaves all the request/response / cookies etc. handling to PHP?
What would be the design decisions involved in creating such a framework? Right now, the only thing I can think of is that it would probably expose an XML/JSON API accessible by the PHP pages using GET and SET function calls.
I can't think of a use case where this makes any sense. If you want something else to handle the HTTP request/response, you'd be better off writing to the Apache API directly.
Introducing PHP gives you argument parsing and cookie handling but also introduces a lot of other silliness. Not only are many of the common practices very unsafe or insecure, but you are limited to content generation -- if you want to dispatch to other parts of code based on the URL you have to write all that yourself. Many mature PHP programs end up just having one "start" PHP script. You also will have problems if you want to do anything interesting with uploaded files, because PHP handles that in a suboptimal way.
You could theoretically do something very processor intensive in your Haskell extension, but you might as well just write a C extension for PHP in that case. And PHP invocations are never supposed to hang around for very long anyway.
Seems like you are limiting yourself to PHP's brain-damaged model of a web application for the very trivial benefit of argument and header parsing.
Writing a Haskell interface to the Apache API could potentially be liberating. You could rely on a battle-tested web server, and also hook into every phase of the Apache request cycle. Apache's way of preforking and killing children every now and then might be a way of dealing with Haskell space leaks, although it's a sledgehammer approach.

PHP-style web development on Ruby: creating microframework for that

In PHP world you can just create index.php file, put some inline code and raw HTML, run Apache and it just works.
There are a lot af talks about bad practices of using inline code an so on. So we won't discuss this theme here, please.
How can I start my Ruby application same way? I want to use ERB for code messing, so it will look this way
# index.rb
<h1>Hello world!</h1>
<div>
1 + 1 = <%= 1 + 1 %>
</div>
So my questions are:
What makes PHP just work.
AFAIU(nderstand) There is native support for HTTP in PHP, so I have to use Rack to support it with Ruby
Some basic knowledge for creating my on "microframework": working with application/http servers (Mongrel, nginx, binding on http port and all such kind of job), working with HTTP requests: sessions, params, GET/POST etc (Rack?), sending responses (ERB templating).
So I can make my own (in educational puprposes) microframework for PHP-style web development with Ruby :D
UPD
What really I want to do is an application wich will just get request url, run just that file and return HTML as a response. Also this application should be allowed to be binded on some port
index.rb
info/about.rb
info/contacts.rb
products/product.rb
so It should parse url localhost/index.rb and run index.rb, localhost/products/product.rb?product_id=10 and run products/product.rb and pass product_id=10 as a params hash.
UPD 2
I think good point to start is to dig into Camping microframework source:
https://github.com/camping/camping
It is about 5Kb weight so I shouldn't be confused in it
It is possible to write CGI scripts with Ruby but this is generally not done because we have better solutions.
One file per page is not a very useful abstraction, it's just the one that PHP supports. Ruby has better ways to abstract a web application (like Sinatra, Rails, or even just Rack) so we prefer to use them.
Putting the file name in the url is another unfortunate side effect of PHP's design. It is implementation revealing and unnecessary (you're not getting a Ruby page, you're getting an HTML page), so we choose not to do that either.
CGI and FCGI in Ruby are also slower than the other solutions. This is not because of some limit on how performant they can be; it's mostly just because the effort to make Ruby web applications faster has been spent in more useful areas like Rack and Rails. No one really uses CGI so no one really cares to make it fast. mod_ruby makes CGI scripts somewhat faster if you really want to go this route, but again: there are better ways.
Apache can run PHP by loading in the mod_php module.
I believe to run ruby you will need to have it installed on the server and have mod_ruby loaded into apache. take a look at: http://www.modruby.net/en/
You are looking for CGI. The Apache modules like mod_php or mod_ruby are just packaging provided for CGI scripts written in PHP or Ruby.

Is it possible not to load the bootstrapping mechanism at every call?

This is not a PHP question, but my expertise is with PHP frameworks.
A lot of frameworks have a bootstrapping (loading of classes and files) mechanism. (Drupal, Zend Framework to name a few)
Everytime that you make a request, the complete bootloading process needs to be repeated. And it can be optimized using APC by automatically caching some intermediate code
The general question is:
For any language, is there any way to not load the complete bootstrapping process? Is there any way of "caching" the state (or starting at) at the end of the bootstraping process to not load everything again? (maybe the answer is in some other language/framework/pattern)
It looks to me as extremely inefficient.
In general, it's quite possible to perform bootstrap / init code once per process, instead of having to reload it for every request. In your specific case, I don't think this is possible with PHP (but my knowledge of PHP is limited). I know I have seen this as a frequently criticism of PHP's architecture... but to be fair to PHP, it's not the only language or framework that does things this way. To go into some detail...
The style of "run everything for every request" came about with "CGI" scripts (c.f. Common Gateway Interface), which were essentially just programs that got executed as a separate process by the webserver whenever a request came in matching the file, and predefined environmental variables would be set providing meta information. The file could be basically any executable, written in any language. Since this was basically the first way anyone came up with of doing server-side scripting, a number of the first languages to integrate into a webserver used the cgi interface, Perl and PHP among them.
To eliminate the inefficiency you identified, the a second method was devised, which used plugins into the webserver itself... for Apache, this includes mod_perl for Perl, and mod_python for Python (the latter now replaced by mod_wsgi for Python). Using these plugins, you could configure the server to identify a program to load once per process, which then does the requisite initialization, loads it's persistent state into memory, and offers up a single function for the server to call whenever there is a request. This can lead to some extremely fast frameworks, as well as things such as easy database connection pooling.
The other solution that was devised was to write a web server (usually stripped down) in the language required, and then use the real webserver to act as a proxy for the complicated requests, while still serving static files directly. This route is also used frequently by Python (quite often via the server provided by the 'Paste' project). It's also used by Java, through the Tomcat webserver. These servers, in turn, offer approximately the same interface as I mentioned in the last paragraph.
The short answer is: in PHP there's no good way to skip the bootstrapping. (Technically you could run a PHP service 24/7 that ran forked children to handle requests, but that's not going to make your life any better.)
A good framework shouldn't do much in bootstrapping. In my personal one that I use, it simply registers an autoload function for classes, loads the config settings from MemCache, and connects to a database.
At that point, it parses the request and sends it to the proper controller / action. While creating the new router object every time is a "waste," the actual process of handling the request needs to be done regardless if the bootstrapping process is magically "cached" between requests.
So I would measure the time it takes between starting the page and getting to the action method to see if it's even a problem. If the framework is doing expensive things related to configuration and class loading, you should be able to minimize that via storing the end results in memcache.
Note that you should always be using an opcode cache (e.g. APC) and a persistent SAPI (e.g., php-fpm) in production. Otherwise, there is a lot of overhead with starting up and shutting down.
I would suggest you to look into FastCGI and C/C++ interface if you want to handle multiple requests. Usually it brings many problems (such as data caching / flushing, memory leaks etc), but can raise performance 10-100 times.
PHP is more suitable for web interface, and if you need fast-processing then you can write a persistent handler.
Also take a look at Java / Tomcat, Python and mod_perl. Some people have also suggested xcache.
For the PHP frameworks they do need to support a multi-request structure in the core, and I'm not aware of any framework doing that.
However said that, I'd love to have a project which would let PHP script to respond to multiple requests inside a loop. Not simultaneously, but bypassing the initialization.
Also you can take a look at https://github.com/kvz/system_daemon, and http://gearman.org/.

Two ways to make python based webpages?

I wanted to try out python to create webpages instead of using php. However I came across that you need either mod_python or mod_wsgi installed to apache to make it play with python. If you now use pure, i'm not sure if it should be said pure, python code, not using any web frameworks like django. I found out that making a simple page looks differently in mod_python and in mod_wsgi.
How come?, the more I looked into python it just seemed to be a harder language to use to make webpages comparing it to php. Is there some good starting point to learn python webdevelopment?
Sorry if my question is blurry. I simply want some guidance to start out with python webdevelopment
Yes, making a webpage with python without using a web framework is harder than it is in php. This is by design, since it gives you a great deal more control over how your page interacts with the server, allowing you to build sites that scale well, among other benefits. WSGI is the modern way to interact with a server, but as you observed, it includes many of the nuts and bolts that PHP hides from the user.
If you're looking for a php-like experience for python, you might look at web.py or Flask. They are pretty minimalistic as far as frameworks go, and take care of interacting with the server but otherwise stay out of your way.
That said, you really should consider Django or another similar framework - they provide some really great benefits that help you get what would otherwise be painfully complex sites going quickly. They solve a slightly different problem and provide different solutions from the common PHP frameworks, so you should consider them even if you don't like frameworks in PHP.
If you want to do things in an even more php-like fashion, you could use CGI. It's definitely not a recommended solution, and won't teach you best practices moving forward, but it can get you started...
Really though, consider a framework. It's how most development in Python for the web is done, and you'll learn more useful skills if you develop using one.
mod_wsgi is better, because it's based on the WSGI specification, which defines the interface between web applications (or frameworks) and web servers. A WSGI app at its simplest is nothing more than a function that sends some HTTP headers via a callback and returns a string in response to information about an HTTP request. And since WSGI is implemented by many web servers, you aren't tied to Apache.
The closest you can get to pure frameworkless web development in Python is to write the WSGI app directly. This will really help you see the things that a framework like Django will obscure.
To make things easier, you might consider using Werkzeug, which is a utility library for WSGI. It has many components that are framework-like, but you can choose which ones you want and which ones you don't. For example, it has a really neat system for parsing and dispatching URLs. Werkzeug also has a simple command-line WSGI server which is probably better for development than Apache.
I'm replying to you with some advice, as someone who was in a very similar situation as you just a few months ago.
So you're using apache to host your website. That's cool. To make python play nice with apache, you're going to want to use mod_wsgi, for the reasons others have stated: seperation of concerns makes it better than cgi and mod_python is no longer being supported.
However, your impression that foregoing a framework will bring you closer to programming in "pure" python is a little bit off the mark. I shared the same opinion, and experimented with both Django and using only mod_wsgi. Let me share what I found.
Mod_wsgi is an implementation of the WSGI standard found in PEP 333. The distinction between the implementation and the standard is important. First, because it means that WSGI compliant applications will work across implementations. More importantly, it reveals something important about what WSGI is meant to do. That is, WSGI is intended a standard for writing frameworks. From the PEP:
simplicity of implementation for a framework author is not the same thing as ease of use for a web application author
and
The goal of WSGI is to facilitate easy interconnection of existing servers and applications or frameworks, not to create a new web framework.
I'm not saying that you shouldn't do something with wsgi, but you should expect to be writing a framework more than an application. If you're interested in writing a simple framework this tutorial is where I started.
However, if you're just looking to make a website, look into one of the frameworks that others have suggested. You'll still be writing python code, but the authors have worked hard to make the code you write closer connected producing websites than producing frameworks. I've personally used Django, and once it was up and running, it was rather painless to churn out interesting applications. Also, their documentation is very good, and they have a good tutorial here. That being said, Django is very fully featured, and if you're looking for something a little more minimalistic, I've heard good things about Flask, but there are lots of other options as well.
You can use ordinary CGI, which is really simple. Create a Python program that looks something like this:
#!/usr/bin/env python
import sys
sys.stdout.write("Content-type: text/html\r\n\r\n")
print("Hello <em>world</em>!")
Make this file executable (chmod +x) and put it in a directory you've configured for CGI files in your web server.
You will also find the standard Python cgi module very helpful.
If your goal is for making your python program web friendly then the answer is Cherrypy. It is a very flexible and simple framework that enables your python objects exposed in web. Check it out and it has a nice web server built-in that you don't need apache/mod_wsgi etc.,

Perl vs. PHP to tar files on a remote server then move them to another remote server

I need to create a web application that tars files on a remote server then moves those files to another server. I am new to scripting languages and was wondering if there are advantages to php or perl for this type of application.
Not really. Both will get the job done just as good as the other. The bottleneck of both will be connecting to the remote server.
PHP was originally derived from Perl, so the syntax between the two are very similar. It's all a matter of taste.
PHP is nice because many Apache servers are setup to allow you to embed PHP code inside your HTML pages. This makes PHP very popular in building things like CMS systems and bulletin boards.
I personally think that the PHP syntax is sloppy. There's way too many specific functions and they're not clearly thought out. The syntax changes from one function to another. I guess it's part of PHP's group based philosophy where a lot of people add a lot of features. I also like Perl's use strict and use warnings pragmas which I find save me a lot of grief.
But, as I said, when it comes to webpage development, PHP is ahead of Perl.
(Yes, I know about modperl, but that's not usually installed in most Apache servers).
I'd say to go ahead and learn both. I believe the Perl books are some of the best written programming guides I've seen. I haven't been too thrilled with the PHP ones. Maybe its because Perl is just more established, so the documentation has been better defined.
Then again, if you're going to learn something, maybe you should try Python. I'm not a fan of Python, but its the up and coming language that most people are learning these days. Google uses Python extensively. And, don't forget Ruby which has the webbased Rails platform that's very popular.
By the way, what you want to do isn't part of the default language, but most languages have modules that are easily installable. For example, you'll need Archive::Tar and LWP for Perl. These can be downloaded from the CPAN module archive.
It's going to take you a while to pick up enough of any language to do what you want, so be patient and have fun.
You need this ssh extension http://php.net/manual/en/book.ssh2.php
It support calling ssh using ssh2_connect.
And you can bundle with tar, scp, or even rsync

Categories