http://qs321.pair.com?node_id=331959


in reply to developing and distributing perl apps

I guess if your customers are not tech savvy they should be using hosted services. Hosted services are generally offered with bundled software installed, usually including (amongst many others) mySQL and Perl (even mod_perl for a price). Just distribute your packages/cgi-scripts bundled up as a PAR and include a database table install script. Easy.

Oh, and you'll need some way of adding your PAR to the mod_perl configuration. Not too hard.

And some way of making sure all your applications dependencies are satisfied. Probably very difficult with a hosted service.

Hmm, how about fully configuring boxes as application specific webservers and shipping the entire package to your customers? Probably not a viable option.

Or maybe your customer will just use the hosted services freely supplied shopping cart application.

rdfield

  • Comment on Re: developing and distributing perl apps

Replies are listed 'Best First'.
Re: Re: developing and distributing perl apps
by techy (Scribe) on Feb 26, 2004 at 14:30 UTC
    rdfield,

    You can add a PAR file to a mod_perl configuration via the Apache::PAR module. Apache::PAR is written for exactly these kinds of situations.

    Dependency checking is probably best avoided by packaging all dependent modules into the PAR file. If this isn't possible, there are a couple of other ways I think dependency checking could probably also be handled:

    • Make the PAR file an executable with pp and have the main script check dependencies. That way, a user could run the par file to check dependencies, but still install it on mod_perl using Apache::PAR (untested)
    • Using Apache::PAR, add code to the web.conf file in the PAR file using a <PERL></PERL> section which checks dependencies, and prints warnings or errors out as appropriate. Of course, this couldn't check for the existance of Apache, mod_perl, PAR or Apache::PAR, as these are prereqs for loading a web.conf

    Thanks,
    techy

[reply]
      Nathan? Is that you? :)

      Script reload still doesn't happen under Apache 1.3.x on Win32, but the module reload is working fine now. I haven't tested 0.30 under Apache 2.0 yet.

      rdfield

[reply]
        rdfield,

        Yes, its me, always looking for a chance to put in a plug for Apache::PAR :-)

        I will take a look at reloading scripts under Win32. Does this happen with both Apache::PAR::Registry and Apache::PAR::PerlRun? Trying Apache 2/mod_perl 2 may be a good idea - Apache::PAR uses a very different system for running Registry/PerlRun scripts under it. In the mean time, if it is appropriate for your application you may also want to try ##UNPACKDIR## in your web.conf and using normal Apache::Registry or Apache::PerlRun config to execute the scripts, as there is also a mechanism for reloading the unpacked content for changed archives.

        Also, I suggest we take this offline as this is slightly OT for this discussion. Can you send me an email with the details?

        Thanks,
        techy (Nathan)

[reply]

In Section Seekers of Perl Wisdom