Evan Gibson writes:
What happens when we have 4 or 5 different types of methods (perl, php, python, c, pascal, whatever...) and through multiple people working on a site or a product you suddenly have them all used and have to suddenly upkeep something you have no idea about because someone else left? Most of the time, I am not at all concerned with the internals of software products. Be they implemented in C, assembler, Perl or whatsoever. Think of compilers, operating systems, databases.
I treat these products as black boxes. If they fail, I look for upgrades, write a bug report, request technical support. If this does not lead to a solution, I look for workarounds. If this proves impossible, a replacement/correction/reimplementation may get a try provided this is sufficiently important for the paying customer. I do not see, why this should be different with Zope products -- provided, they have a clear interface (should be not a big problem, if they can be called via HTTP), a decent documentation and they do what the documentations promisses. and about the costs to try to fix the situation myself.
Mostly this is a concern for individual sites to decide whether they want to risk contamination or not and it's certainly an option they _should_ have, but I'd like to ask that once Perl methods are out there that the products downloadable from the zope site be split into those that are "pure" python and dtml versus those that have other types of methods in them. I think, this is important mainly for experimental software. For field proved products, an indication of the implementation language may improve trust that in case of problems, I can more easily fix it. If, however, the product is sufficiently complex, understanding the product is much more difficult than learning the implementation language (e.g. a C++ compiler versus the C implementation language).
Dieter