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
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.
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).
Zope maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -