Nevertheless, Paul is *still* trying to get someone to scratch his itch, even if he's stopped projecting that onto me. Problem is that nobody *can* even if they were willing. Until someone at DC is actually assigned to take the minimum time needed to get up to speed on this there simply isn't anything anyone *could* do to "make it easier".
I have a really super-rough time understanding this outlook. Zope is a framework. On top of it you can build whatever you like, including a complicated ecommerce application. Why is it absolutely, unwaveringly, overwhelmingly necessary for *DC* specifically to be involved in an application-level project like a port of ACS' ecommerce module when it's not clear that it can generate any immediate revenue for us? Is this not just an application? We've provided the tools to get the job done (relational database adapters, object persistence, DTML, PythonScripts, sessions, the list goes on), we're still in the process of providing the necessary API, developer- and user-level documentation for Zope use and development, and we (along with the rest of the community) provide pretty darn good tech support every day via this list. What is time better spent? Working on docs or working on the ecommerce scopeout? DC *is* in the application space with the CMF. But it's its own product with its own set of internal developers, and there's not a terrible amount of crossover between the "core" team and the CMF team work areas. This to me represents a healthy division of "framework" vs. "application". The CMF team never asks the core team to develop a workflow module. They do that. I *think* what you're getting at is that you want DC to build an interface that mimics the tcl interface to the Oracle/Postgres tables that make up the ecommerce application. If not, please help me understand this. You've tried to do so, but I think I've missed the argument. It'd be helpful for the answer to be in twenty words or less. I'm sorry, I just can't parse these multipage multiconcept messages.