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

Martijn Faassen wrote:

The addition of the Perl stuff will be bad if the Zope source will be hacked up in various places in order to support this. I can be _good_ if this means a focus on providing clean interfaces first, and a more componentized architecture. I.e. there's a focus on integration with *any* external language through some generalized API. Not just Perl specific changes.

Believe me, the Zope sources are being hacked up more for DOM/XSLT than for Perl! :^) Seriously, there aren't any changes to Zope being proposed for Perl Methods. Actually, the only changes are positive ones -- a "Methodgeddon", meaning a Method Armageddon. The work on XSLT Methods and Perl Methods has exposed a need for a coherent model between all the methods, particularly how things are bound. Thus, the white hot spotlight of bringing in more kinds of methods have made us look at the cruft and inconsistencies. --Paul

Martijn Faassen wrote:

Jimmie Houchin wrote:

...

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.

Sure, but we also need to encourage people to study each other's products, and debug them, and implement patches. Open source development and all.

...

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.

So we need interfaces, and a more componentized architecture.

I personally don't _want_ black box products. One one side, most products should work as if they're black boxes. Clear API, managable through the web, and so on. On the other side however, in practice I'll want to take a look at the product source once in a while, to fix something, or to find out how it's working.

I agree here in one way. I too want the ability to be able to extend, modify or fix a product. Here Perl will affect me if I choose to use anything Perl as I do not know Perl. However, I believe there is a distinction between types of Zope developers. You have the Zope user which takes the various products available. Plugs them into their places, configures them via their management screens, etc. This user will approach all products as black boxes regardless of implementation language. Odds are they don't know any of the implementation languages. Then you have the developer. The person who creates the products. This person should do it well enough that the above person does not need to be concerned about anything more than it working as described. The developer should also do it well enough that fellow developers can come aboard and extend, modify, debug and fix the product. Understanding the two distinct user groups is important. It is like the zope list and the zope-dev list. I personally have no plans on using Perl. I will also not make predictions as to it's future benefit or liability. We will kind of have to watch to find out. I did not have any problems with Zope being Python only, but am open to a bigger vision. Jimmie Houchin [snip]

Regards,

Martijn