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
##### CGI::Application community mailing list ################
## ##
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp ##
## ##
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
## ##
################################################################
