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
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 -