[cgiapp] Re: Perl Certified Hosting

[Lyle]

Mark Stosberg wrote:
> As a CPAN author and the owner of a hosting company, I see flaws with both
> approaches:
>
> - As a host, I understand cPanel's policy of not giving c-compiler access to
>   users. I like it when module chains offer a pure-perl alternative.
>   

As a host I understand this as well. Neither projects involve giving c 
compiler access to users. I also like pure perl alternatives.

> - Having hosts provide a standard set of modules with standard versions is just
>   a bad idea. YAPC featured multiple presentations on why to distribute the
>   "stack" (of dependencies) with your application, and I have written about it
>   myself. Indeed, it is one of the goals of Titanium.
>   

I also include the stack (for the most part) for my software. Although 
this project is a good idea. It gives you more options, you can still do 
you stack, there are always going to be issues with specific versions, 
but the benefits far outweigh the downfalls. Version compatibility 
effects all language modules from vb, .net to php, with anything an 
upgrade can always cause things to brake. If people are relying on the 
modules to be on the host because of the Perl Certified Hosting program, 
then they'll have to expect to keep up with version changes. They'll 
also have the opportunity to test their software against the latest perl 
certified hosting version before it is released.

  My CPAN project is designed to make it possible to easily package your 
stack for shared hosting whether the modules are XS or PP.

>   This just further encourages module authors to support bad API designs
>   because they are backwards compatibile.
>   

Backwards compatibility doesn't necessarily mean bad API design.

> The solutions I see don't involve Perl-certified hosting:
>
> 1. Ship the dependency stack with your application. Projects like 'local::lib'
> make this easier to do. search.cpan.org or some other side could automate it,
> providing you a tar file of dependencies for any module you wanted, possibly
> in a way that prefers Pure Perl code over XS.
>   
> 2. Secure access to compiling on the target platform as needed, whether you compile
> directly on the target host, on a compatible system, or find ways to avoid XS code
> altogether. (Increasingly, that's my preference). 
>   

Both sound very similar to:-
http://perl.bristolbath.org/projects/cpan.html


Lyle