I would like to echo what Dieter wrote here. We need to encourage people who write products or other extensions to Zope in writing cleanly, clearly defined extensions which can be used in a black box manner. If each product had a management interface in which it's options could be configured and it had a clear api. We could treat these as black boxes regardless of implementation language. This is true even for those of us who prefer Python. A Python product written with disregard to the above can still be difficult and ugly to use. This would open up Zope as a platform for web development. If this is DC's intent then this needs to written up on best practices or coding standards for writing Zope products etc. This would help tremendously when you have a clear separation between user of a product and developer of a product. Jimmie Houchin Dieter Maurer wrote:
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