Oh boy! It's even thougher then I thought... Well, my forum is being converted into OO (for version 2) right now, so that will be easier to convert.. But still, I'm confused.. I never thought it would be so difficult... Because if I ever get that mod_perl in my program, it would be a very cool.

In the next version of my forum, I eliminated almost all standard modules.. Especially CGI.pm ... I'm frustrated of what that module loads... Defaultly it even loads 'overload.pm', which is only used for multipart-data (file uploads) etc etc.. I think there is too much overhead. (also elimitated vars.pm... that's indirectly loading a lot too) The only think I have lefty is strict now.

Fortunately, I have been using strict and -w from the beginning... That's the biggest culture shock for mod_perl newbies I guess...

No __DATA__ Flags at the end of your script, or __END__ flags, either I believe.

Mod_Perl is a stricter "language" than perl, which involves making sure we don't have memory leaks, etc. You'll get them even if you are strict and warnings compliant.

Modules are *good*, modular coding attests to your abilities, in now way does it detract from them. A well defined object orriented structure in your modules will make your script clean and simple, it will also make modification heaps easier.

If you're not using CGI;, then I hope you're using the appropriate Apache modules.

Oh... the __END__ tokens are only used in the modules, to stop perl reading through the included pod documentation.

Also, I need to read the docs carefully about some "re-initializing" subroutines. Some variabels need to be reset after running.

Also I wonder: My next version reads in a sortof ini-files containing the settings. That's because I think it's easier to edit, and doesn't make end-users cause Perl errors. The settings read are filled into a hash, so they can be re-used by all other modules easier.

I wonder, when should I empty that hash? Every time? When I detect the file has changed? (and how do I check that?) This saves memory, but generates more IO.

>> Oh... the __END__ tokens are only used in the modules, to stop perl reading through the included pod documentation. <<

Using __END__ with mod_perl is ok.

>> Also, I need to read the docs carefully about some "re-initializing" subroutines. Some variabels need to be reset after running. <<

Use END and DESTROY blocks in your modules to reset globals and try to clear out anything that may not be reset under mod_perl...you can add this code into your cgi script which will get executed on every request...eg...

Paul, I was under the impression that __END__ tokens were not alright in mod_perl *scripts*, but were alright in handlers....

As you know scripts are converted into temp handlers some how (I'm not advanced enough to understand the process...) The script is then executed, but will get screwed up as __END__ will stop the last } to close the sub handler.... It's documented as well... so I'm pretty sure it's true.... ( Check my OO thread in intermediate...)

Simply put, mod_perl is a software package that embeds a Perl interpreter into the Apache HTTP server, giving the developer access to the Apache module API from within Perl. This allows you to build Apache module server extentions in Perl, rather than in C. Don't worry if this definition seems a bit like techo-babble at the moment. You will soon see what this description means, and how mod_perl can help you to create advanced, high-volume Web applications quickly and easily.

About the __EXIT__ and __DATA__ tokens -->

Apache::Registry scripts cannot contain __END__ or __DATA__ tokens.

Why? Because Apache::Registry scripts are being wrapped into a subroutine called handler