On Mon, Sep 15, 2008 at 11:06 PM, Mark Stosberg <[EMAIL PROTECTED]> wrote: > - 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. > > The reality that module upgrades can and do make incompatible changes, even > when they aren't intended. I've done it myself, with Data::FormValidator and > CGI::Application. So, if you tell hosts "provide CGI.pm 2.95" and then later > tell them "Ok, the standard has been updated, now you just provided CGI.pm > 3.3", then given enough users of the system, someone's code will break in the > upgrade.
Do hosting companies ever upgrade outside of the standard packaging system of their OS vendor? Do they ever upgrade OS version on a production server? I thought they would not exactly because of the above risk but I am not in the hosting business and in the past 8 years I think I only used full servers not shared hosting. So this is just my guess. I was impressed by the "stack" presentation of JT on YAPC but IMHO the "stack" of what you supply will greatly depend on all kinds of things. On one hand for some people it is ok to supply only their own code, on the other hand others will go as far as wanting to supply "appliances". That is everything including the hardware. In between there are those who supply all their non-standard perl dependencies and those who supply perl as well. I think we, as in the Perl community, should help to improve all the possibilities. Well, maybe we don't need to deal with the appliance part nor even with the "provide the whole customized OS" version. My suggestion would improve the "lowest" level of integration, when the developer only supplies the code s/he wrote. Titanium on the other hand aims at the middle somewhere which is also extremely important but as far as I understand neither the OS distributors nor the hosting companies have any role in that project. regards Gabor ##### 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/ ## ## ## ################################################################
