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
> Regards,
> Martijn

Zope maillist  -  [EMAIL PROTECTED]
**   No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to