hello.. An very interesting thread this.. thank you It seems to me that a real danger here is the magical scope/vagueness of the term "e-commerce". Surely an appropriate e-commerce """solution""" depends on who what why where when and how..? No silver bullets - as much about people, workflow, money and politics as it is about technology, tools and architectures. These are still very early e-days. I believe that many post-dotcomboom e-sites, in their selection of tools/systems, will be heavily focused on balancing ease of start-up vs. long term maintenance issues. Consider various e-contexts: A> Large well established business [existing market infrastructure] wanting to move some or all of their non-web business into a web-based system.. sales management admin.. total content and management B> Similar well established business who wants to start a new spinoff web-based e-business. Basically marketing cataloging sales etc.. C> A new business targeted directly at web from the getgo. No legacy technology or politics.. D> Non-commercial, such as public services, [libraries, schools, goverments, cooperatives, non-profits, communities, fundrasiers, etc] = entities who have the need of selling somethings/services online, and/or test the process in an adaptible [low-cost] manner. E> Government and NGOs in countries where OpenSource+Linux is now becoming official, or strategic policy [Korea, China, France etc], who are looking for Content Management Systems but naturally need some e-capability. They are primarily focused on selecting intelligently, longterm system architectures, development platforms, the right design philosophy etc etc.... F> add your own here.. IMO, The #1 e-commerce success issue for Zope is not adding prepackaged [fast track analysis] e-commerce packages, but 1. the growth of Python, and 2. access to a stable, brilliantly conceived, stable, documented Zope API. These are the essential foundations. With these it is possible for real-world applications by any [A-F] above to take place. It is possible for the thiving community to expand far wider, for ZopeNewbies to get up to speed in much more competititive time, for Technical Directors to say 'Yes!' ... and for talented and knowledgable 1st, 2nd, or 3rd parties to create useful, effective e-commerce packages/services. Without the brilliantly conceived and documented ZAPI, I do not see how any cool potent ambitious port of any other system or OORDBMS is going to cut it commercially beyond unique great-hearted experiment stage. Except when used by innovative, talented small groups of people, who are very likely closely related to the people on the zope list already. Specifically, I like Paul's comment that OpenACS should perhaps be looked as as requirements document. I suspect that makes better sense than trying to 'port' it. Zope needs needs more tangible rational file-oriented options to allow it to dovetail wiht other tools. And if I read it right, this is happening by DC and 3rd party effort already. Likewise concretely examining and analysing the Postgresql OpenACS for porting potential, as Albert suggests can probably only be a useful step. But evaluating it must also be done with honest regard to the sobering vagueness and what is E-Commerce? To my eyes and ears, None can answer that, but I would love to hear your opinions , and what you consider to be Zope priorities for this.. It is true external Relational DB product connectivity is a major item for Zope, but I find it very interesting to see a growing effort by several Python programmers to develop ZODB in new ways. This can surely only be good for Zope and any E-commerce projects using it. Pervading e-wisdom seems to recommend separation of financial transaction mechanisms from the others: catloguing, ordering, etc. And I would expect to see this separatoin deepen as banks and others get their own APIs sorted out, the lack of which is partly what got us into this mess in the firstplace.
From there on it's a commodity and leaves people tofocus on the applcation itself not the financial transaction headaches and responsibilities. Since peer to peer is still a hot meme, we can expect a lot of 'alternative' experiments to be run. The first place those programmes wil look is to a suitable object oriented system and Zope shuold be brigh on their radar, expecially as the best of 2.xxx PEPs make in into Python modules.. stackless, embedded, ..
I hope this makes sense - Jason ___________________________________________________________ Jason CUNLIFFE = NOMADICS['Interactive Art and Technology'] PS.