...

"Components need not be persistent, nor provide a management interface." - I think this is a mistake. They should. Any component / bean has to be configured and the best way for the end user is to configure it through the GUI. Windows 3.0 ).

Not necessarily. Take for instance a component "XMLParser". There's no configuration that needs to be done to it. It's a black box. It needn't be persistent, because it is instantiated on the fly as needed. It needn't be configured because there are no knobs to it. Yet it has an introspectable interface.

There is no black boxes in this world, I think. Even XMLParser could be configured. Ideally, each and every component in this world has at least one confugurable property. Debug="on/off" and it is convinient if this property could be set from the GUI at any point of time. For XMLparser it can also be "Validating/non-validating". In fact, it could also be : "report all the errors into separate log-file". Not talking about configurable extrenal entity resolver ( for complex XML cases ). Also it could be "cache the XML file storing it into SAX-bytecode to avoid the parsing" e t.c. e t.c. Well, in fact, even it is not a big deal to make Zope's log-file rotating, hacking the z2.py with rotating_file_logger(LOG_PATH, freq='daily'), I think you should agree that this configuration should be done with the GUI. I agree that there are some entities which will have no need in GUI configuration, but I think the number of those entities is actually small and ( more important ) I'm interested *not* in such entities, but in the easy way of building some really trivial thinghs ( like TutorialPoll ) in straightfoward way in the assumption, for example, that each such thing will have not more than just one configuration screen, but it seems that this configuration screen *has* to be in the design. Again - think about Windows 3.0. For complex things there was Window, for 'no-GUI' things there is no APIs, but there was also Dialog box! Modal Window with straightforward auto-adjustable GUI. Current Products are 'Window' Components are 'no GUI' I'm talking about the 'Dialog Box' things. Again - if we're talking about turning Zope into unbeatable "Windows 3.0".

Some instances of components will definitely need to be configured via a GUI (just like Products are now). But the definition of "component" as it stands is just an object with an introspectable interface. What we think of now as "Products" will likely be special components that happen to offer a web interface (possibly via one or more "adapters") and a set of instantiable classes. But some components may not offer a web interface, and others may not offer persistent instantiable classes.

This means there is simply no entity for the "Dialog Box" because I'm talking neither about the Producs, nor about the Compoments, but about the 'Simplified Products'. ( TinyTable, ParsedXML e t.c. )

...

I understand the desire to stay out of XML, but try to use simple text formats. The problem is that simple text formats do not scale.

I mean that

requires "Zope" "2.3" or better requires "FooProduct" "1.0" exactly requires "SpamProduct" "0.1" or "0.2" or "0.5"

could occasionally become

requires "FooProduct" "1.0" exactly requires "SpamProduct" "0.1" or "0.2" or "0.5"

exports "something_here"

Or god knows what. Designing really good ProductDescriptor It is like designing the *darn* complex SQL schema and going with the "simple table" first in the hope that it will be possible to tune the schema "when needed" may by suspicious step.

This needs to be thought out more. We need to understand the requirements better, and work out a design. Will the product machinery need to resolve circular dependencies? What does "or better" mean? This is something for the Fishbowl at http://dev.zope.org. The design step is the hardest part, and this is where we can use the most help!

I see two things here. 1. 'Dialog Boxes' ( simplified Products with GUI ) 2. 'CPAN' ( first - for Dialog Boxes ) I think it could initially all the things could be placed in just one ProductDescriptor.XML file This will be a foundation for most complex things and will significantly decrease a mess. BTW - writing XML for DialogBoxes could be done manually with no problem. No need in any tool. 1. Write The Python file which implements the semantics of TrivialPoll. 2. Write the XML, describing dependecies and configurable things ( This describes Zope integration ) Pretty clear separation, no ? The interaction with Zope will be generated for you. ( this is the point ). I think this may help to productize a lot of things.

...

What particular list is appropriate for this discussion?

The Zope list probably (zope@zope.org). Amos Lattierer asked for comments on the roadmap document on the Zope list, so it's certainly on-topic.

Rgds.Paul. PS. See also. http://www.pault.com/X/983148775/index_html http://dev.zope.org/Wikis/DevSite/Proposals/FinishedProductGuidelines