Recently I was trying to make some mod_perl 1.0 module compatible with mod_perl 2.0 (at the same time), and saw all the differences in the new mod_perl 2.0.

First off please remember that mod_perl 2.0 is not finished yet. As far as I am aware there isn't a date for a point release in sight. There are certainly many holes in the documentation and a few in the implementation. I'm sure the developers would welcome patches ;-)

If you just need to run some mod_perl 1.0 code under mod_perl 2.0 take a look at Apache::compat. If this isn't working for you please submit a bug report to the development team.

First, I didn't like all the changes made in mod_perl 2.0, since is not so easy/fast to make the script working in the new mod_perl. And since I don't think that mod_perl is intuitive. mod_perl 1.0 isn't intuitive (the developers really need to learn some stuffs to use it), and mod_perl 2.0 is even more not intuitive.

This, of course, depends on your intuitions! mod_perl is different from CGI scripting. mod_perl 2.0 is different from mod_perl 1.0. It has to be to allow you to gain many of the advantages of having direct access to the Apache 2 environment, and to fix the lessons learned from the mod_perl 1.0 implementation.

If you're used to event-driven, multi-threaded client-server coding then the Apache 2 / mod_perl 2.0 model should make sense.

Personally I've not found my experience of mod_perl 2.0 any less intuitive that mod_perl 1.0. Do you have any specific examples in mind?

First, whe need to always return a constant for all the sub handlers. Well, on mod_perl 1.0 this is only an option.

Sorry, don't understand what you're getting at here...

2nd, a lot of methods are in different namespaces. Soo, we stay a long time testing the code and finding the new names or locations for the methods. mod_perl 2.0 has a module to help on that, but a little list in the docs of mod_perl 2.0 with the methods that were changed or doesn't exists any more will be good.

You mean like the Reference to mod_perl 1.0 to mod_perl 2.0 Migration :-)

The breaking up of the API into more modules and name spaces is a good think since the mod_perl 1.0 API was much to monolithic and hard to extend.

3rd, the output doesn't work like in CGI, where you just print to STDOUT. To get a good output you really need to call print() from the apache object: $apache->print(). We still have STDOUT, but will work strange for complex output flux. Also to flush, $|=1 doesn't work, you need to call rflush() for each flush.

It is hard to have simple STDOUT based output work in an environment where you can, for example, have an output stream that consists of open filehandles and pipes moving through filters that can arbitrarily buffer data running in an multi-threaded environment. Treating everything as a simple stream of characters just isn't practical in the general case.

Actually for CGI scripts is too hard to have them working on mod_perl 2.0. Is much better to rewrite them.

Of course it is. The same is true of mod_perl 1.0. If you don't rewrite your CGI scripts you're going to miss many of the advantages of the mod_perl environment.

That said, if you do just want to run CGI scripts under mod_perl 2.0 then ModPerl::RegistryBB, ModPerl::Registry and ModPerl::PerlRun should be all you need. If you're having problems with them then I'm sure that a polite message to the mod_perl list will get you some help.

Actually the biggest problem is that to use mod_perl 2.0 we have a lot of new things. For example, to test mod_perl 2.0 I was using Apache 2.0, Perl-5.8.1 and mod_perl 1.99. And for mod_perl 1.0 I was using Apache 1.3+, Perl-5.6.1 and mod_perl 1.29. Soo, the changes are not only in mod_perl, but in each chunk of software.

Since the reason mod_perl 2.0 exists is so we can take advantage of Apache 2.x features like filters and threading it's hardly surprising that you need to upgrade :-)

Soo, what the monks think about mod_perl 2.0? Are you using/testing it? How it's working?

Personally I'm not using it on any live sites at the moment since (IMHO) it's not yet ready for production work. The documentation hasn't been finished and I don't have the spare time to grok the source - as facinating as it looks.

I've played with a bit on dev boxes and am looking forward to some of it's features - it's going to make some Perl/Apache work a lot easier in the future.

For example, the ability to assign different Perl interpreters to different virtual hosts suddenly means that mod_perl becomes a much more attractive option for ISPs in shared hosting environments.

It sounds to me that the problems that you're encountering are just artefacts of the current incomplete state of the mod_perl 2.0 project. Once mod_perl 2.0 gets a point release out of the door I think many of your difficulties will disappear with the existence of improved documentation / features.