[ZCommerce] RE: Philip leaves Arsdigita (was: Re: [Zope] kerberos ? + LDAP + ecommerce + ZEO replication etc)

[Jason Cunliffe]

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.