[Michael Bernstein] Albert Langer wrote:

Right now arsDigita is going through a major upheaval and it looks like OpenACS will provide an umbrella home for various ports of ACS 4, including python/Zope as well as their main orientation to Tcl. The data model of ACS4 is now much better separated from the Tcl side and they are doing a Query Dispatcher for supporting multiple RDBMS ports (with some tools in python for extracting SQL from the Tcl code completely ;-).

http://developer.arsdigita.com/commerce-project-central/

http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg%5fid=000b5M&topic%5fid

=web%2fdb&topic=

http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg%5fid=000ZGz&topic%5fid

=web%2fdb&topic=

Wow. This is a shocker. I'm glad that Digital Creations seems to have managed the process of creating and nuturing a community around their product much better. Another perspective on this can be found here: http://joel.editthispage.com/stories/storyReader$305 Michael Bernstein. [Albert] Sorry I buried the Arsdigita news among so many other things. BTW among the other things, I just discovered that kerberos 5 kerberized sockets for python were done in December 1999, but have been unable to locate any recent updates. http://starship.python.net/crew/fdrake/manuals/ http://ftp.jussieu.fr/pub/python/contrib-09-Dec-1999/System/ Now back to the main story... ACS4 SQL is even using a Domain Object Model pattern with properly OO separation of a meta-data knowledge layer from operational layer in the RDBMS, with an access control system acquiring permissions from context, sophisticated Party/Group/Roles relationships that can express the whole UML concept of associations and based on accountability patterns from Fowler's "Analysis Patterns", a powerful petri net based workflow engine etc etc. Arsdigita has stopped Tcl development and moved to java. What more could a Zope guru want to persuade them to take a look at the possibility of demonstrating how much better that fits with Zope than with java or Tcl? Oh yes - one more thing - an important Open Source community that has RDBMS skills somewhat lacking in the Zope Community, currently faced with upheavals in Arsdigita and actively working on a demonstrably viable escape route from Oracle and welcoming lots of new involvement. Seems that isn't enough though. No sign of interest from DC. Anybody listening? See my original posting: http://lists.zope.org/pipermail/zope/2001-March/086365.html Plain fact is that Zope *still* lacks an industrial strength RDBMS based ecommerce system that could have a huge impact in getting Zope widely deployed at ISPs, which is critical to getting lots more interest. Postgresql is now *fully* "industrial strength" (outer joins, better performance than Oracle and a python procedural language much better than Oracle java or PL/SQL just released). Right now when *lots* of people are getting involved in OpenACS and are doing a port of ACS4 for *both* Oracle and Postgresql 7.1 the opportunity is wide open for getting real momentum behind adding the strengths of the ACS RDBMS datamodel to the strengths of Zope. All the SQL previously mixed in with Tcl cruft is just sitting there waiting to be Zoped. The reasons for deferring it earlier ("it would take at least a week to study" and "got to resolve API documentation first") cannot possibly still apply. Everything else that could possibly be going well for Zope is obviously going amazingly well, and will continue to do so if somebody did spend a week or two on taking a look. Yet this key aspect for getting wide deployment is still being neglected. I haven't been hassling anybody about this for nearly a year, so I guess it's time for some CCing. Sure hope somebody who can do something about it reads the above link to previous posting concerning the ACS4 developments - and the links within it and then assigns some actual *resources*. On the first anniversary of having first pointed out that a viable ecommerce package would not happen without DC involvement and without checking out ACS, I go on the war path. That's not far off ;-) You don't get turnkey ecommerce packages without actual resources being put into a coordinated effort. It's the coordination and serious interest and commitment from DC that is lacking - there's no lack of prototypes showing that Zope is a perfectly suitable platform for the UI web side of ecommerce as well as content management (when and only when used together with an industrial strength RDBMS such as postgresql - nobody in their right mind does serious ecommerce without that). A project like the CMF could get this done *fast*. BTW another recent posting not responded to re Zope SSL support is pretty relevant to this as well: http://lists.zope.org/pipermail/zope/2001-April/086937.html

I agree with your suggestion that ecommerce based on OpenACS4 should be "fishbowled" and will even count that as expressing "interest". However after nearly a year, and at this particular moment, it is nowhere near *enough* interest because of events that have just happened and are happening right now. I also agree that in asking DC to put some resources into it: '...the question that needs to be answered is "How does it immediately help DC to reimplement the ACS ecommerce module inside Zope?" The answer so far hasn't been compelling enough for a project to be created.' and that: 'DC has limited resources, and making a committment to port the ACS ecommerce module can't possibly be done without being able to see a tangible monetary benefit to DC as a company.' How *could* a compelling enough answer to that question for a project to be created be available if nobody from DC has actually studied the recent events to seek an answer? So who is to answer that question? A grassroots community effort? Why should we, if it so happens that we merely wish DC well and are very appreciative of DC having made possible the benefits of Zope for the things we *are* interested in, but do *not* have a focus on tangible monetary benefit to DC as a company? The only way *that* question can be answered is by DC staffers being assigned to take a look and answer it. It can't be answered by me having said that I've taken a very close look and concluded that DC would have the most to gain from getting it done quickly. Nor can it be answered by you off the top of your head. It can only be answered by someone from DC taking the time (I believe your estimate of a week, made nearly a year ago is reasonable), to checkout what's been happening with arsDigita and OpenACS very recently and thoroughly review both the ACS4 documentation and code and what interest DC might have in a solid turnkey ecommerce package and an escape route from Oracle in it's commercial contracts. It certainly can't be answered by waiting to see if someone *else* stands to gain enough from this job being done to take up the mantle of actually carrying it through. All I'm going to do is make suggestions. I'll certainly help if there *is* a fishbowl project, but I'm in no position to get one started. I doubt that *anyone* other than DC "stands to gain the most benefit". Likewise the various people who have been working on various Zope based ecommerce projects would be very likely to help but have shown no likelihood of being able to deliver what is needed to carry it through without some sort of coordinated effort sponsored by DC. You *don't* need to wait to see whether a grassroots effort is the solution. There has been one for more than a year in the zcommerce list and it very obviously is *not* the solution. Has DC gained any "tangible monetary benefit" from that at all? vvvvv

What more could a Zope guru want to persuade them to take a look at the possibility of demonstrating how much better that fits with Zope than with java or Tcl?

Manpower. ;-) ^^^^^ Well manpower is one of the major benefits you could get from taking that look. You've already got grassroots efforts doing "presentation" of ecommerce with Zope and there's no big problem doing the catalog side using ZODB (though an ORDBMS has advantages there too). But your core competency does not lie in ORDBMS SQL and neither does that of the grassroots Zope community. (Nor in the simpler matter of protocols communicating with payments gateways for that matter - wampum is still "pre-alpha" and there is nothing for any service except cybercash - which is in deep trouble). An entirely separate company has put major resources into an SQL data model that is freely available open source. That saves an awful lot of manpower, just as many companies using Zope have been saved a lot of manpower by the resources DC has put into it. An entirely separate open source community is right now putting major grass roots resources of highly skilled SQL programmers into porting the SQL so that data model can be used with *both* Oracle *and* Postgresql 7.1 and separating it entirely from the Tcl and java - mainly for convenience in doing that - but with the obvious consequence that it will be much easier to move it from the relatively clumsy web application framework they have got, to Zope. That saves an awful lot of manpower too. A third open source community has put major resources into turning postgresql 7.1 into an industrial strength RDBMS quite capable of replacing Oracle in many situations, which is also about to get python as a built in backend procedural language. That's not so much a savings in manpower as something that couldn't be done with any amount of manpower from DC, but is now available to DC. Now DC seems to have had to put quite a bit of resources into maintaining an Oracle adaptor for python, which I suspect is not entirely within your core competency. I would guess that there would be at least *some* contracts that DC depends on for revenue where the customer spends at least as much on Oracle licenses as they do on consulting, so you ought to be able to figure out that there exists at least a possibility worth investigating that being able to demonstrate that what they want works with Zope *both* on Oracle and on a free ORDBMS could result in some tangible monetary benefit to DC (even if they only have to buy *less* Oracle licenses with Zope/ZEO acting as an intermediary between postgresql backed web servers and Oracle stuff working with internal systems). I would also guess that there would be at least *some* contracts that DC has *not* gained because the reason the customer wants the sort of things Zope does provide is closely connected with also wanting to charge for various goods and services that go with it and they decide they would prefer to deal with consultants that have a better track record on ecommerce. I'm just guessing of course. Only DC can determine whether these, and/or other matters might result in tangible monetary benefit to DC. But the direct benefit to DC that I highlighted was the benefit that is also a direct benefit to the whole Zope community that I am more interested in. The more widely Zope is known and used the stronger it grows and the more consulting revenue DC gets, since people who can afford to pay for consultants are quite happy to do so, but like to have heard that what they want specially tailored is widely adopted and mainstream. ISPs already have web servers and don't need Zope for what they are currently doing (though if *they* had manpower to take a close look, which they generally don't, they'd see some good reasons for using Zope too). They also need to put in "commerce servers" and come up with some quite bizarre solutions using perl and MySQL or else have to pay through the nose. If Zope had an industrial strength turnkey commerce server it would be widely used by ISPs and would become "mainstream" like Apache - the Zope community would benefit greatly and DC's consulting revenue would grow greatly. Now how much do *I* get paid for trying to get DC to take a look? If you win this argument you aren't going to get any tangible monetary benefit for DC either. If somebody *does* take a look you just might. Think about it. -----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Chris McDonough Sent: Tuesday, April 03, 2001 7:25 AM To: Albert.Langer@Directory-Designs.org; 'Michael R. Bernstein' Cc: 'Mayers, Philip J'; zope@zope.org; zcommerce@codeit.com Subject: Re: [ZCommerce] RE: Philip leaves Arsdigita (was: Re: [Zope] kerberos ? + LDAP + ecommerce + ZEO replication etc)

Now back to the main story...

ACS4 SQL is even using a Domain Object Model pattern with properly OO separation of a meta-data knowledge layer from operational layer in the RDBMS, with an access control system acquiring permissions from context, sophisticated Party/Group/Roles relationships that can express the whole UML concept of associations and based on accountability patterns from Fowler's "Analysis Patterns", a powerful petri net based workflow engine etc etc. Arsdigita has stopped Tcl development and moved to java.

What more could a Zope guru want to persuade them to take a look at the possibility of demonstrating how much better that fits with Zope than with java or Tcl?

Manpower. ;-)

Oh yes - one more thing - an important Open Source community that has RDBMS skills somewhat lacking in the Zope Community, currently faced with upheavals in Arsdigita and actively working on a demonstrably viable escape route from Oracle and welcoming lots of new involvement.

Seems that isn't enough though. No sign of interest from DC.

Lots of interest, not a lot of time. This is a great fishbowl idea and community development effort idea.

Anybody listening?

See my original posting: http://lists.zope.org/pipermail/zope/2001-March/086365.html

Plain fact is that Zope *still* lacks an industrial strength RDBMS based ecommerce system that could have a huge impact in getting Zope widely deployed at ISPs, which is critical to getting lots more interest. Postgresql is now *fully* "industrial strength" (outer joins, better performance than Oracle and a python procedural language much better than Oracle java or PL/SQL just released).

Right now when *lots* of people are getting involved in OpenACS and are doing a port of ACS4 for *both* Oracle and Postgresql 7.1 the opportunity is wide open for getting real momentum behind adding the strengths of the ACS RDBMS datamodel to the strengths of Zope. All the SQL previously mixed in with Tcl cruft is just sitting there waiting to be Zoped.

The reasons for deferring it earlier ("it would take at least a week to study" and "got to resolve API documentation first") cannot possibly still apply.

Everything else that could possibly be going well for Zope is obviously going amazingly well, and will continue to do so if somebody did spend a week or two on taking a look. Yet this key aspect for getting wide deployment is still being neglected.

I haven't been hassling anybody about this for nearly a year, so I guess it's time for some CCing.

Sure hope somebody who can do something about it reads the above link to previous posting concerning the ACS4 developments - and the links within it and then assigns some actual *resources*.

On the first anniversary of having first pointed out that a viable ecommerce package would not happen without DC involvement and without checking out ACS, I go on the war path. That's not far off ;-)

You don't get turnkey ecommerce packages without actual resources being put into a coordinated effort. It's the coordination and serious interest and commitment from DC that is lacking - there's no lack of prototypes showing that Zope is a perfectly suitable platform for the UI web side of ecommerce as well as content management (when and only when used together with an industrial strength RDBMS such as postgresql - nobody in their right mind does serious ecommerce without that). A project like the CMF could get this done *fast*.

BTW another recent posting not responded to re Zope SSL support is pretty relevant to this as well:

http://lists.zope.org/pipermail/zope/2001-April/086937.html

I think the question that needs to be answered is "How does it immediately help DC to reimplement the ACS ecommerce module inside Zope?" The answer so far hasn't been compelling enough for a project to be created. That's not to say it won't become so in the future or that it's not a worthwhile effort. But DC has limited resources, and making a committment to port the ACS ecommerce module can't possibly be done without being able to see a tangible monetary benefit to DC as a company. OTOH, look at ZPatterns. DC literally had (and still has) nothing whatsoever to do with ZPatterns. However, lots of people use it, it's quite popular. I think the same could be done with a grassroots effort to get the ACS module moved to Zope. DC did provide help to Phillip and Ty in the way of implementing changes to Zope that made it easier for ZPatterns to do what it does, because we understand that it's a good long-term investment to do so. I think the relationship with DC and a group of folks who wanted to port ACS ecommerce to Zope would probably best follow the same pattern. I suggest that this project be fishbowled and those who are interested and who stand to gain the most benefit take up the mantle of actually implementing it. - C _______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )

[Chris McDonough] Please note that the email I sent does not count as an "official DC response". I probably should just keep my mouth shut, but I felt that your plea deserved a response (I didn't want to see it slip through the cracks) and it's the best I could do at the moment. I haven't the authority to make any sort of real decision regarding any DC involvement in the porting of the openacs ecommerce package to Zope. Here are the people that do: paul@digicool.com rob@digicool.com jim@digicool.com I'm bowing out now, because any further commentary from me is just so much hot air. - C [Albert] Fair enough, address list amended accordingly ;-) BTW providing a response rather than letting it slip through the cracks was *exactly* the right thing to do. Your straight forward response provided the necessary confirmation that deciding what to do about these developments isn't currently on the agenda among DC staffers and can therefore lead to that being corrected if somebody does take a look at the links and decides it does need to be corrected - whereas silence or a more mealy mouthed response would have just let it slip through the cracks. Signing off for now, hoping for an "official" DC response, and hoping it will *not* come immediately (though a reassuring note would be nice ;-) but after enough time for somebody to have taken a look. Thanks. Seeya, Albert Albert Langer wrote:

I agree with your suggestion that ecommerce based on OpenACS4 should be "fishbowled" and will even count that as expressing "interest".

However after nearly a year, and at this particular moment, it is nowhere near *enough* interest because of events that have just happened and are happening right now.

I also agree that in asking DC to put some resources into it:

'...the question that needs to be answered is "How does it immediately help DC to reimplement the ACS ecommerce module inside Zope?" The answer

so

far hasn't been compelling enough for a project to be created.'

and that:

'DC has limited resources, and making a committment to port the ACS ecommerce module can't possibly be done without being able to see a tangible monetary benefit to DC as a company.'

How *could* a compelling enough answer to that question for a project to be created be available if nobody from DC has actually studied the recent events to seek an answer?

So who is to answer that question? A grassroots community effort? Why should we, if it so happens that we merely wish DC well and are very appreciative of DC having made possible the benefits of Zope for the things we *are* interested in, but do *not* have a focus on tangible monetary benefit to DC as a company?

The only way *that* question can be answered is by DC staffers being assigned to take a look and answer it. It can't be answered by me having said that I've taken a very close look and concluded that DC would have the most to gain from getting it done quickly. Nor can it be answered by you off the top of your head.

It can only be answered by someone from DC taking the time (I believe your estimate of a week, made nearly a year ago is reasonable), to checkout what's been happening with arsDigita and OpenACS very recently and thoroughly review both the ACS4 documentation and code and what interest DC might have in a solid turnkey ecommerce package and an escape route from Oracle in it's commercial contracts.

It certainly can't be answered by waiting to see if someone *else* stands to gain enough from this job being done to take up the mantle of actually carrying it through.

All I'm going to do is make suggestions. I'll certainly help if there *is* a fishbowl project, but I'm in no position to get one started. I doubt that *anyone* other than DC "stands to gain the most benefit".

Likewise the various people who have been working on various Zope based ecommerce projects would be very likely to help but have shown no likelihood of being able to deliver what is needed to carry it through without some sort of coordinated effort sponsored by DC. You *don't* need to wait to see whether a grassroots effort is the solution. There has been one for more than a year in the zcommerce list and it very obviously is *not* the solution. Has DC gained any "tangible monetary benefit" from that at all?

vvvvv

...

What more could a Zope guru want to persuade them to take a look at the possibility of demonstrating how much better that fits with Zope than with java or Tcl?

Manpower. ;-) ^^^^^

Well manpower is one of the major benefits you could get from taking that look.

You've already got grassroots efforts doing "presentation" of ecommerce with Zope and there's no big problem doing the catalog side using ZODB (though an ORDBMS has advantages there too).

But your core competency does not lie in ORDBMS SQL and neither does that of the grassroots Zope community. (Nor in the simpler matter of protocols communicating with payments gateways for that matter - wampum is still "pre-alpha" and there is nothing for any service except cybercash - which is in deep trouble).

An entirely separate company has put major resources into an SQL data model that is freely available open source. That saves an awful lot of manpower, just as many companies using Zope have been saved a lot of manpower by the resources DC has put into it.

An entirely separate open source community is right now putting major grass roots resources of highly skilled SQL programmers into porting the SQL so that data model can be used with *both* Oracle *and* Postgresql 7.1 and separating it entirely from the Tcl and java - mainly for convenience in doing that - but with the obvious consequence that it will be much easier to move it from the relatively clumsy web application framework they have got, to Zope. That saves an awful lot of manpower too.

A third open source community has put major resources into turning postgresql 7.1 into an industrial strength RDBMS quite capable of replacing Oracle in many situations, which is also about to get python as a built in backend procedural language.

That's not so much a savings in manpower as something that couldn't be done with any amount of manpower from DC, but is now available to DC.

Now DC seems to have had to put quite a bit of resources into maintaining an Oracle adaptor for python, which I suspect is not entirely within your core competency.

I would guess that there would be at least *some* contracts that DC depends on for revenue where the customer spends at least as much on Oracle licenses as they do on consulting, so you ought to be able to figure out that there exists at least a possibility worth investigating that being able to demonstrate that what they want works with Zope *both* on Oracle and on a free ORDBMS could result in some tangible monetary benefit to DC (even if they only have to buy *less* Oracle licenses with Zope/ZEO acting as an intermediary between postgresql backed web servers and Oracle stuff working with internal systems).

I would also guess that there would be at least *some* contracts that DC has *not* gained because the reason the customer wants the sort of things Zope does provide is closely connected with also wanting to charge for various goods and services that go with it and they decide they would prefer to deal with consultants that have a better track record on ecommerce.

I'm just guessing of course. Only DC can determine whether these, and/or other matters might result in tangible monetary benefit to DC.

But the direct benefit to DC that I highlighted was the benefit that is also a direct benefit to the whole Zope community that I am more interested in.

The more widely Zope is known and used the stronger it grows and the more consulting revenue DC gets, since people who can afford to pay for consultants are quite happy to do so, but like to have heard that what they want specially tailored is widely adopted and mainstream.

ISPs already have web servers and don't need Zope for what they are currently doing (though if *they* had manpower to take a close look, which they generally don't, they'd see some good reasons for using Zope too).

They also need to put in "commerce servers" and come up with some quite bizarre solutions using perl and MySQL or else have to pay through the nose.

If Zope had an industrial strength turnkey commerce server it would be widely used by ISPs and would become "mainstream" like Apache - the Zope community would benefit greatly and DC's consulting revenue would grow greatly.

Now how much do *I* get paid for trying to get DC to take a look?

If you win this argument you aren't going to get any tangible monetary benefit for DC either.

If somebody *does* take a look you just might. Think about it.

-----Original Message----- From: zope-admin@zope.org [mailto:zope-admin@zope.org]On Behalf Of Chris McDonough Sent: Tuesday, April 03, 2001 7:25 AM To: Albert.Langer@Directory-Designs.org; 'Michael R. Bernstein' Cc: 'Mayers, Philip J'; zope@zope.org; zcommerce@codeit.com Subject: Re: [ZCommerce] RE: Philip leaves Arsdigita (was: Re: [Zope] kerberos ? + LDAP + ecommerce + ZEO replication etc)

...

Now back to the main story...

ACS4 SQL is even using a Domain Object Model pattern with properly OO separation of a meta-data knowledge layer from operational layer in the RDBMS, with an access control system acquiring permissions from context, sophisticated Party/Group/Roles relationships that can express the whole UML concept of associations and based on accountability patterns from Fowler's "Analysis Patterns", a powerful petri net based workflow engine etc etc. Arsdigita has stopped Tcl development and moved to java.

What more could a Zope guru want to persuade them to take a look at the possibility of demonstrating how much better that fits with Zope than with java or Tcl?

Manpower. ;-)

...

Oh yes - one more thing - an important Open Source community that has RDBMS skills somewhat lacking in the Zope Community, currently faced with upheavals in Arsdigita and actively working on a demonstrably viable escape route from Oracle and welcoming lots of new involvement.

Seems that isn't enough though. No sign of interest from DC.

Lots of interest, not a lot of time. This is a great fishbowl idea and community development effort idea.

...

Anybody listening?

See my original posting: http://lists.zope.org/pipermail/zope/2001-March/086365.html

Plain fact is that Zope *still* lacks an industrial strength RDBMS based ecommerce system that could have a huge impact in getting Zope widely deployed at ISPs, which is critical to getting lots more interest. Postgresql is now *fully* "industrial strength" (outer joins, better performance than Oracle and a python procedural language much better than Oracle java or PL/SQL just released).

Right now when *lots* of people are getting involved in OpenACS and are doing a port of ACS4 for *both* Oracle and Postgresql 7.1 the opportunity is wide open for getting real momentum behind adding the strengths of the ACS RDBMS datamodel to the strengths of Zope. All the SQL previously mixed in with Tcl cruft is just sitting there waiting to be Zoped.

The reasons for deferring it earlier ("it would take at least a week to study" and "got to resolve API documentation first") cannot possibly still apply.

Everything else that could possibly be going well for Zope is obviously going amazingly well, and will continue to do so if somebody did spend a week or two on taking a look. Yet this key aspect for getting wide deployment is still being neglected.

I haven't been hassling anybody about this for nearly a year, so I guess it's time for some CCing.

Sure hope somebody who can do something about it reads the above link to previous posting concerning the ACS4 developments - and the links within it and then assigns some actual *resources*.

On the first anniversary of having first pointed out that a viable ecommerce package would not happen without DC involvement and without checking out ACS, I go on the war path. That's not far off ;-)

You don't get turnkey ecommerce packages without actual resources being put into a coordinated effort. It's the coordination and serious interest and commitment from DC that is lacking - there's no lack of prototypes showing that Zope is a perfectly suitable platform for the UI web side of ecommerce as well as content management (when and only when used together with an industrial strength RDBMS such as postgresql - nobody in their right mind does serious ecommerce without that). A project like the CMF could get this done *fast*.

BTW another recent posting not responded to re Zope SSL support is pretty relevant to this as well:

http://lists.zope.org/pipermail/zope/2001-April/086937.html

I think the question that needs to be answered is "How does it immediately help DC to reimplement the ACS ecommerce module inside Zope?" The answer so far hasn't been compelling enough for a project to be created. That's not to say it won't become so in the future or that it's not a worthwhile effort. But DC has limited resources, and making a committment to port the ACS ecommerce module can't possibly be done without being able to see a tangible monetary benefit to DC as a company.

OTOH, look at ZPatterns. DC literally had (and still has) nothing whatsoever to do with ZPatterns. However, lots of people use it, it's quite popular. I think the same could be done with a grassroots effort to get the ACS module moved to Zope. DC did provide help to Phillip and Ty in the way of implementing changes to Zope that made it easier for ZPatterns to do what it does, because we understand that it's a good long-term investment to do so. I think the relationship with DC and a group of folks who wanted to port ACS ecommerce to Zope would probably best follow the same pattern.

I suggest that this project be fishbowled and those who are interested and who stand to gain the most benefit take up the mantle of actually implementing it.

- C

_______________________________________________ Zope maillist - Zope@zope.org http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev )

_______________________________________________ ZCommerce Mailing List - ZCommerce@codeit.com http://lists.codeit.com/mailman/listinfo/zcommerce

_______________________________________________ ZCommerce Mailing List - ZCommerce@codeit.com http://lists.codeit.com/mailman/listinfo/zcommerce

Walter Ludwick wrote:

Hey, Albert: I'm a newbie to the ZCommerce list (and to the Zope world in general), but this thread of yours has really piqued my interest.

Uhh, mine as well. :^) It's an important, serious point. Thanks for chiming in. Comments below.

I've just concluded a project (a CMS for a group of federated websites with a kinda half-assed "eCommerce" component) in Zope, simply because ACS was too expensive for us at this point, and we needed a quick/ cheap win. The

Was there anything about Zope (especially as a CMS), beyond quick/cheap, that was a win?

project has proven successful, and i believe we did indeed chose wisely; nonetheless, as we look at the major challenges to be addressed in the next phase of development (i.e. PERSONALIZATION), i don't see anything "on the

Can you explain personalization? The CMF (formerly PTK) does some of personalization, but I wonder what parts it doesn't address of "personalization" as you see it.

shelf" in the Zope world that comes close to addressing the needs, and the ACS looks increasingly attractive.

But i'm missing a lot of the background, and having a bit of trouble following this thread, so maybe you can tell me: is it possible that we could port the ACS functionality into our Zope-based CMS as a "plug-in," and could this be the sort of business rationale that Digital Creations needs to hear in order to justify the expensive of a person-week to do the sort of analysis that you seem to be requesting?

There are a number of alternatives. As you described, we could view ACS as a requirements document and port it. We could try to find a way to make Zope a frontend for ACS' e-commerce, or vice versa. I haven't heard much specifics about how this might work, so I can't comment on it.

It certainly seems to me that ACS is eating Zope's lunch in the market for "serious" eCommerce solutions - and now that the WorldBank is investing so

That's probably true. eCommerce, as is obvious, hasn't been the place we've chosen to compete. But it's hard to be competitive in other areas without some ecommerce story.

much in the ACS through this "Gateway" project of theirs, with no corresponding investments in the Zope world, the trend can only worsen. So it seems to this particular buyer in the market (small potatoes as i am) that incorporating ACS functionality into Zope, instead of just waiting for someone to happen along and fund its development from scratch, is the

Understand, of course, that this applies to *lots* of things. And saying that DC has to eat it out of hide is OK, but there's a limit to how much we can apply that strategy to.

smarter way -- maybe even the only way -- to make it happen. Without industrial-strength eCommerce and all that personalization stuff that goes along with it and is so important to everyone these days, i'm afraid that Digital Creations may be relegating Zope to the prospect of diminishing returns in a market that will just have to expand without significant Zope/DC participation. If this is what you've been trying to tell Chris McD, then i'm afraid i have to agree.

You're certainly right that, if Zope wants to be competitive in eCommerce, then it needs an eCommerce story. The story is a bit murkier for competing in other areas, but it's likely that Zope should have at least *some* production-class story for eCommerce. For personalization, depends on you definition. We might alread have some of it. But concerning the remedy...is it *truly* the case that DC has to own this effort? After all, many of you know more about eCommerce than us. We definately should participate, though. --Paul

[...] [Walter]

...

I've just concluded a project (a CMS for a group of federated websites with a kinda half-assed "eCommerce" component) in Zope, simply because ACS was too expensive for us at this point, and we needed a quick/ cheap win. The [...] project has proven successful, and i believe we did indeed chose wisely; nonetheless, as we look at the major challenges to be addressed in the next phase of development (i.e. PERSONALIZATION), i don't see anything "on the

[Paul]

Can you explain personalization? The CMF (formerly PTK) does some of personalization, but I wonder what parts it doesn't address of "personalization" as you see it.

[Walter] Big question, Paul. I could say a lot about this, but then i'd be quickly out of my depth in technical discussion. Let's just put it this way: Amazon has taught us all a lot about how eCommerce sites can adapt dynamically to user preferences and choices in such a way as to sell more stuff WHILE building stronger customer relationships -- and ARS Digita has taken great pains to build a lot of the business logic behind such magic into their systems. eCommerce isn't just about a shopping cart that remembers your choices for the duration of a single session, but more about maximizing Lifetime Customer Value. ARS Digita has turnkey applications/ modules for managing this, i gather, the likes of which i have never heard of in the Zope world. But maybe i am missing somthing i should know about -- so, like Ross Perot, i'm all ears :-) |/|/ [Albert] A good starting point for understanding what ACS does along these lines is Philip Greenspan's online book (also available as an elegant coffee table edition for the suits, with the same stunningly beautiful and irrelevant photos ;-) http://www.arsdigita.com/books/panda/ Especially chapters 9 and 14. The whole book is also necessary reading for a serious study of what ACS is (or was) about. BTW I agree with Charlie Cook that a lot of what Amazon does has more to do with "collaborative filtering" than "personalization". Though collaborative filtering isn't just a "marketing aid" and the specialized algorithms originated from open source projects like GroupLens (for collaborative filtering Usenet news groups) which I remember tracking closely at the time. Also agree with Jason Cunliffe that "peer to peer" has close connections with ecommerce and Zope should be of great interest to people interested in peer to peer. Collaborative filtering and peer to peer (which are *very* closely related) is actually more where I'm coming from than "ecommerce" - but for achieving mass penetration the connection with ecommerce has been close enough to deserve serious study. (Only responded with "condescending" advice as to how DC could achieve "tangible monetary gain" because I was explicitly *asked* to do so). [Walter]

...

shelf" in the Zope world that comes close to addressing the needs, and the ACS looks increasingly attractive.

But i'm missing a lot of the background, and having a bit of trouble following this thread, so maybe you can tell me: is it possible that we could port the ACS functionality into our Zope-based CMS as a "plug-in," and could this be the sort of business rationale that Digital Creations needs to hear in order to justify the expensive of a person-week to do the sort of analysis that you seem to be requesting?

[Paul]

There are a number of alternatives. As you described, we could view ACS as a requirements document and port it. We could try to find a way to make Zope a frontend for ACS' e-commerce, or vice versa.

I haven't heard much specifics about how this might work, so I can't comment on it.

[Albert] I can comment on it, as requested by Walter. Last time I did was in the following messages from June and July 2000: http://lists.codeit.com/pipermail/zcommerce/2000-June/000257.html http://lists.codeit.com/pipermail/zcommerce/2000-June/000259.html http://lists.codeit.com/pipermail/zcommerce/2000-June/000265.html http://lists.codeit.com/pipermail/zcommerce/2000-July/000316.html As Paul mentioned, I haven't posted anything since. A lot has changed since then - most important being that ACS *has* adopted the database independence layer I highlighted as missing. Perhaps if Paul had actually read it rather than just checking whether I was "contributing" to zcommerce, he would have noticed it included an offer to spend a couple of weeks doing UML diagrams. Same message also included an offer to email anyone interested the relevant SQL (DDL). Perhaps if that hadn't been completely ignored at the time, Paul would have more specifics and be better able to comment. For an "executive overview" on why very few people are contributing to the zcommerce list see someone else's later message that starts with: "After 2 months of struggling with Etailer, EMarket, and ZCommerce I give up!" http://lists.codeit.com/pipermail/zcommerce/2001-February/000371.html The "high level" alternatives Paul mentions above confirm my "clairvoyant" view that there hasn't been much study at DC of what's going on in ACS, and OpenACS. Both the "requirements" and "vice versa" options are simply irrelevant. An inability to respond to Walter's simple question about the third option Paul mentioned, and having to resort to talking about such "alternatives" ought to be sufficient for someone at DC to be assigned to find out what it's all about. As to the even "higher level" comment from Paul: "[...] I've been watching ArsDigita, ACS, and OpenACS. There's seems to be a LOT of tumult going on there. Open Source developers in particular seem jaded by the events. Shouldn't that factor into your opinion? Nahh, everything seems pretty clear to you." The reality is that OpenACS is being flooded with these "jaded" open source developers keen to work on it: http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0001AP&topic_id=12&to pic=OpenACS%204%2e0%20Design Above also includes some links to ACS ecommerce issues. [Walter] Obviously i haven't got a clue about the how-to's. Maybe some of the Zope/ ACS geeks out there do, and can advise. FWIW, i am inclined to believe that a move like this, if it's to be successful, is not driven by programmers, but rather from the perspective of meeting real business needs. I've got plenty of those to talk about, and there's plenty more where i'm coming from. But without some analyst(s) at the table -- saavy about products on both Zope and ACS sides and their feature-sets -- it'll be like the sound of one hand clapping. I for one am interested enough in this topic to explore it further, but not if Digital Creations isn't. |/|/ [Albert] That's pretty much my perspective too. In another message Paul said: "I'd like to emphasize that Albert's idea has merit. We'd like to learn more about the idea, as we don't know as much as we should about it. But someone needs to make it easier for us -- unfortunately, it's just reality that we don't have as much time to investigate possibilities as we would like." That's a distinct improvement on the previous: "I'll confess, I'm viewing this thread through the lens of hearing "I've got a great idea for someone else to do." It's hard to separate the attitude from the merit of the idea. The idea has merit, that's certainly true." 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". When someone at DC is assigned to spend a week or so looking into it, I'll be happy to offer suggestions to that person as to things to look at - though much better advice to "make it easier" could be available from someone actually involved by just going through the list at the link above. [Walter]

...

It certainly seems to me that ACS is eating Zope's lunch in the market for "serious" eCommerce solutions - and now that the WorldBank is investing so

[Paul]

That's probably true. eCommerce, as is obvious, hasn't been the place we've chosen to compete. But it's hard to be competitive in other areas without some ecommerce story.

[Walter] Quite so. |/|/

...

much in the ACS through this "Gateway" project of theirs, with no corresponding investments in the Zope world, the trend can only worsen. So it seems to this particular buyer in the market (small potatoes as i am) that incorporating ACS functionality into Zope, instead of just waiting for someone to happen along and fund its development from scratch, is the

[Paul]

Understand, of course, that this applies to *lots* of things. And saying that DC has to eat it out of hide is OK, but there's a limit to how much we can apply that strategy to.

[Walter] Fair enough. You obviously can't commit resources without seeing tangible proofs of interest in the marketplace. |/|/

...

smarter way -- maybe even the only way -- to make it happen. Without industrial-strength eCommerce and all that personalization stuff that goes along with it and is so important to everyone these days, i'm afraid that Digital Creations may be relegating Zope to the prospect of diminishing returns in a market that will just have to expand without significant Zope/DC participation. If this is what you've been trying to tell Chris McD, then i'm afraid i have to agree.

[Paul]

You're certainly right that, if Zope wants to be competitive in eCommerce, then it needs an eCommerce story. The story is a bit murkier for competing in other areas, but it's likely that Zope should have at least *some* production-class story for eCommerce.

For personalization, depends on you definition. We might alread have some of it.

[Walter] Whaddya got? I've still got my ears on... |/|/ [Paul]

But concerning the remedy...is it *truly* the case that DC has to own this effort? After all, many of you know more about eCommerce than us. We definately should participate, though.

--Paul

[Walter] You certainly shouldn't be going it alone, Paul. Without the interest of both the developer community AND business people in search of solutions, this effort would likely not succeed. But, presuming for a moment that the subscribers to this list could muster enough developers and business solution-buyers to warrant it, might you be willing to dedicate project management and technical expertise enough to do a proper opportunity analysis? IMO, unless DC is serious enough about this issue to make at least that sort of commitment, this worthy project is probably a non-starter. |/|/alt Walter Ludwick wludwick@mail.walmar.com [Albert] I agree with Walter, and with Paul agreeing with Walter ;-) On Paul's question concerning the remedy, the parts that DC has to "own" are the APIs for application developers to work with and the implementation of those APIs for: a) Talking to the OpenACS SQL (there may be several layers here). b) Talking to payment's gateways (a generic interface plus a couple of sample implementations that are *not* clearly labelled "use of this pre-alpha software for handling other people's money could be grounds for a negligence suit"). A *lot* more than that might be needed for DC to be a serious contender for big contracts in ecommerce - more in understanding the market rather than software development. (Knowing why MiniVend/Akopia is *not* a "good choice" would for example be essential). But that's the bare minimum - and a very quick and easy way to get an "ecommerce story". With that minimum there are indeed lots of people who could take it from there. Without it they can't. Almost immediate result would be simple shopping carts much better than MiniVend/Akopia that would get widely adopted by ISPs and give Zope some "brand recognition" during the longer time it would take DC to get a real understanding of what Walter was talking about re "personalization" and start getting serious contracts revenue as a result of Zope being a much better platform for the application server end than ACS java. BTW, by "own" I mean being the "ringleader" initiating a fishbowl and ensuring it was carried through to completion. I certainly do *not* mean that OpenACS would be interested in joining with Zope. The cultures are *very* different. Ask Chris ;-) Just leave the SQL to them - they know what they are doing. ACS has regarded the application server as "just plumbing", between the SQL and the web server - as confirmed by having simply abandoned further work with AOLserver and Tcl in favor of different application server for essentially the same "product" in ACS 4 java. There's nothing much that could or should be "ported" in the OpenACS Tcl. All DC needs to do is standardize python/Zope interfaces to the underlying SQL engine (I don't mean DAs to the database engine, but a Zopish replacement, not port, for the fairly thin layers done in Tcl). I am *not* "suggesting that OpenACS would switch web application frameworks". I do believe that Zope has a better application framework than what can be done with AOLserver/Tcl or java. Others, quite reasonably, won't believe that until they see it done.

Chris McDonough wrote:

...

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?

I think Albert's saying (forgive me for speaking for you if I get this wrong) that no-one but DC can evaluate the opportunity and make the decision if DC should do this work. Of course, merely *evaluating* the opportunity is a lot of work, and there are too many opportunities for DC to even evaluate them all. If they tried, they would not have the resources left to capitalize on any of them. Albert also (in my opinion) seems to be confusing this type of application level project with the type of infrastructure that DC has to date concentrated on building into Zope. the ZCommerce interest group probably did not gain momentum because (like many projects) it was too ambitious at the outset, and because (also like many projects) it lacked a cohesive vision for what was to be accomplished. Attempts merely to define the scope were bogged down in competing visions. I'm pointing no fingers, as I was as guilty of contributing to the confusion with 'wouldn't it be cool if...' statements as anyone else. Nevertheless, some people *did* do some work, and others did contribute suggestions that eventually became features in one product or another. So I would say that it has been successful and valuable, in a way. Since, to date, commerce has not been a large part of the projects and consulting engagements that DC has been involved in, it may be a good idea for DC to describe what sort of consulting engagements it *has* been involved in. I don't think that any of us in the Zope community begrudge DC their success, and we'd like to be able to make more informed suggestions, rather than shooting from the hip as it were. For that matter, what community contributed products or code is DC using in their consulting work (if any)? When does someone in the community really hit the mark and provide something that is not just popular with other Zope developers, but with the developers at DC as well? That kind of feedback on application level work as well as 'core' work (such as Python Scripts nee Methods), can be very important and valuable. Right now, I have no idea if (for example) DC has ever installed Squishdot for a client, much less any of a number of other projects such as ZPatterns. Anyway, that's my $0.02, Michael Bernstein.

PS: The last msg to come in while i was laboring over my last (like a fool, it now appears) really begs a response. (Now it's my turn to get "torqued"

:-<

on 4/5/01 4:23 AM, Chris McDonough at chrism@digicool.com wrote:

...

I think Albert's saying (forgive me for speaking for you if I get this wrong) that no-one but DC can evaluate the opportunity and make the decision if DC should do this work.

I'd like you to figure out whether you'd like to mow my law, Michael. There's big things in it for you. Get back to me in a week, please. ;-)

YO, dude: Analogies are odious, but this one really stinks. Neither Albert nor Michael, nor anybody else in attendance here asked you to analyze the opportunity of mowing his lawn, or anything of the sort. While we all see something to gain in the opportunity arena we've been attempting to scope out (else why are we even talking?), let us not kid ourselves about who it is that stands to gain the most. Yeesh. I must confess that this whole business of free software development is new to me (less than a year). I am not a programmer. I do however employ programmers -- too many of them, alas (for more info, ask Kaivo Inc., who've provided me with two good ones [a small majority of the total, alas] over the last six months, since they bravely accepted from your company the handoff of our RFP, on the very eve of proposal due date). Over the last decade, i have run more software projects and paid more programmers than i care to remember. I cite these facts to let you know, i am no piker in this domain, panhandling for a free lunch. In fact the landscape of this turf, dear Chris (ridiculous as it is to talk about intellectual properties as though they were physical properties, enjoyment of which is *inversely* proportional to the number of people sharing them) looks to most of us here a bit more like this: We are all busy professionals, and those of us that don't work for DC are over here in *your* sandbox, doing our best to contribute substantially to the intellectual capital of *your* enterprise (remember, it is DC's stock that rises or falls in direct proportion to the installed user-base of Python/ Zope -- certainly not mine), in the hope that we can enjoy a somewhat beter experience as tenants in this commons whose future is under your defacto control (i.e. if you say Zope is for Content Managment, and i say it's for eCommerce and/or eCommunity, we all know who wins the argument). But who wants to engage in any such ridiculous argument? We all agree that Zope can and should do all this stuff; the only argument i see going on here is some sort of pissing contest over who is the busiest. That's a conversation i have no interest in whatsoever -- as is the case, i suspect, with *most* of us here. I've only joined the conversation here because the prospect of eCommerce in Zope (up to now an oxymoron -- rather like "military intelligence," or "jumbo shrimp") appeared for a fleeting moment like something worth talking about. If that was just a mirage on the horizon, forgive me; been thirsty too long, i guess. I guess somebody here needs a long weekend to think about priorities; i for one sure do. |/|/alt Walter Ludwick wludwick@mail.walmar.com

Hey, Chris: No worries, man; no more gargantuan e-mails from me, that i promise. I'll be brief (leaving off the overwrought analogies should save mucho time:) |/|/ on 4/5/01 3:49 PM, Chris McDonough at chrism@digicool.com wrote:

I'd *love* to see this project scoped out.

Oh, good. |/|/

I just bristle at the notion that *DC* absolutely, incontravertably has to "own" it

Nobody has to own anything they don't want, of course. I've been talking all along in terms of *shared* ownership -- until your remark about me wanting you to mow *my* lawn. At that point, all the air went out of my "let's scope-out this problem together" balloon. |/|/

We've decided to concentrate on the content management space, which has so far only proved to be tangentially related to ecommerce. If you don't like this, I'm sorry, and we'll need to agree to disagree.

In fact i applaud this focus (did so explicitly in my mini-SWOT analysis). I just thought, this being the ZCommerce list and all... y'know, maybe it might be ok to bat the old e-commerce ball around a bit here. Guess i wandered into the wrong place; s'cuse me! |/|/

Furthermore, I don't even think you and Albert are talking about the same problem. I believe Albert is talking specifically about porting ACS' ecommerce module to Zope. You want collaborative filtering and personalization. They aren't necessarily even related. We've been talking about OpenACS' ecommerce module as if it's the holy grail, but are you sure it solves your actual problem?

I stopped looking for the holy grail in technology circles many moons ago. But i've been around this game long enough that i can match solutions up with problems as well as most solution-buyers. OpenACS is no cure-all, but it does solve a lot of problems that Zope doesn't, which problems have for me (and many others, from what i gather) grown to the point of warranting (additional) investment. |/|/

Have you thought about what it doesn't have that you want?

Yes. |/|/

To address the rest of your mail, I don't doubt your experience nor do I think that having a Zope "ecommerce story" is a bad idea. My problem is understanding how it's possible that DC *needs* to do this.

Nobody needs to do anything about anything, in fact. You do what you do, ignore what you ignore. And there are consequences. |/|/

Do you think we're just a bunch of guys sitting around without a plan who need to have some structure put in to our lives or what?

No. |/|/

I will reiterate that Zope is a platform. You can build on it what you like. Please, go ahead! Don't wait for us!

- C

Got it loud and clear. Next business problem i see that seems to warrant my investment, i know who not to consult. Thanks for the time/money-saving pointer, Chris. |/|/alt Walter Ludwick wludwick@mail.walmar.com

I've responded to Walter privately about this thread. You are correct, and I don't intend to post publically any more on this issue. I am *not* an "official DC spokesperson", as you note.

You previously announced that you weren't speaking for DC and anything more you said would be just hot air. As I'm re-reading this, I've just noticed Walter, having responded. Instead of treating whatever you say as "hot air", he's treating you as some sort of spokesperson for DC and drawing the obvious conclusion. That's dumb - he should know you are just full of hot air, since you are at least honest enough to admit it when you bungle (that is sincere). So I don't have time to polish this up and am leaving the rest unedited in the hope of catching him before he unsubscribes. It's the aggro version which I usually leave for 24 hours before re-writing.

I specifically asked for an "official" reply *not* to be given immediately.

Paul gave one immediately, half of which was bristling and the other half saying that I had a point. Last few messages I saw included him saying:

"To tell the truth, I'm mad at myself for responding strongly, particularly as our position on this is weak. The folks in zcommerce have been doing the work, not DC, so I didn't have much right to get torqued. And besides, his idea has merit."

I haven't (yet) seen messages from zcommerce developers saying they are pissed off. I have noticed one from someone associated with EMarket expressing interest in similar ideas as Walter about some things. That was also the situation a year ago when another one mentioned moving to ZPatterns to be able to support RDBMS access in response to a posting on OpenACS.

Walter's given some answers and I haven't seen an "official" response yet. I got the impression Walter *was* waving some money around. He's certainly in an industry that needs exactly what's been talked about For a CTO with 30 years experience in a low tech services industry that doesn't usually have CTO's, he has a remarkably deep understanding of why. The dotcoms don't need DC's consulting services - they need a miracle. Sectors like where Walter's coming from do. You are talking to him like you don't even know he's one of your customers and want him to be one of your open source developers. Have you even looked up where he's coming from?

It would be odd if Walter wasn't keen enough on getting the job done to help pay for it - and odd if he couldn't see possibilities of recovering the costs from others with similar needs. But he's obviously been doing some research and he *said* he wants to help pay for it while you are abusing him for not doing so, when I'm quite sure you really meant to be abusing me (which doesn't worry me in the least - at least you got it right - I am not offering to help pay for it).

Now he's pissed off - and that doesn't help either.

When starting off this thread I mentioned I'd be going on the warpath on the first anniversary of having raised the issue. That isn't until 6 June and I don't have time to get *really* pissed off until then. So give me a break, please.

If I wanted to get pissed off I'd have got pissed off at being told to read Eric Raymond on what open source is about - but I managed to just ignore it. The only reason I can't just ignore you is because you insist on announcing what you believe I think.

If occurs to me that you might be doing that with respect to DC too.

If an "official decision" has been taken and you've been told to deliver the news the way you are, please say so. Otherwise, please take Walter's suggestion to let it go over the long weekend (and Walter, please take your own suggestion too). Sheesh I'm a *professional agitator* by trade - my role in this sort of thing is to beat CEO's around the head with clubs until they get angry enough to start looking for arguments to prove I'm wrong and they are right, after which I can just move on because they aren't stupid and know what to do when they can't come up with those arguments. It doesn't win friends, but it does influence people. I just don't have *time* to be telling junior staffers not to piss of the CTO of one of their customer's. So many heads to beat,... so little time (sigh ;-)

I just wanted to chime in at this point to say, I couldn't have put it better myself. I think the 2.3 version number can be misleading. I still see Zope as a very young product, but what we've got so far is so good, you can only be optimistic about its future. Eventually someone (maybe DC) will write an ecom Product, when they need it. I don't really think it is the responsibility of DC to push it forward. seb * Jimmie Houchin <jhouchin@texoma.net> [010406 05:57]:

Walter, Albert, etc...

DC has committed no offense here. They've committed no fouls.

A few facts seem to be ignored in these pleas.

<snip> <snip>

Ownership is really a poor term to describe truly open source software such as Zope. Stewardship is a much better term. No offense intended towards anyone here. I just wanted to state my opinion on DC and on this matter. I have been a long time member of this community, since it was a Bobo list, before Zope was open sourced.

Jimmie Houchin

[jimmie] Walter, Albert, etc... DC has committed no offense here. They've committed no fouls. A few facts seem to be ignored in these pleas. Ownership is really a poor term to describe truly open source software such as Zope. Stewardship is a much better term. DC has stated that: 1. Resources are limited. Read the list, there are many pleas for various things for which DC doesn't have the resources for. 2. They are willing to make accommodations for people who are "contributing" to Zope and need something in core Zope to enable or improve Zope for said feature. 3. They are concentrating on their core interest/skills which currently is Content Management. [albert] Thanks for your comments. I recall your encouragement to take a look at Zope in an OpenACS bboard nearly a year ago and am responding in detail. I wasn't pleading but telling them about an opportunity, which Walter confirmed by promptly waving money together with a detailed analysis of requirements. http://lists.codeit.com/pipermail/zcommerce/2001-April/000418.html My understanding is that this is a common business model often used for obtaining resources. Other models such as issuing IPOs are becoming less and less plausible as time goes on. In responding I'm also attempting to signoff from the direction that has been taken in the thread I started so I can get back to the far more interesting stuff in messages from Walter and other lurkers that joined in, but seem to have been overlooked as a result of the absurd preoccupation with rationalizing DC's position instead of dealing with it's consequences. (I'm not referring to Chris's position, and am assuming that is not what jimmie is defending). So this is an attempt to summarize. Re ownership/stewardship I'm using the term used by DC. My understanding is that they are using it with a substantially similar meaning to "stewardship". In this context it refers to someone being responsibile for the ongoing maintenance and development of some software component. (Not necessarily by doing it themselves but having both the authority to take decisions about what must be done and the responsibility to ensure that those decisions are taken and those things are done). Whether rhetorically or not, the question Paul asked his customer Walter is central: "But concerning the remedy...is it *truly* the case that DC has to own this effort? After all, many of you know more about eCommerce than us. We definately should participate, though." My answer is "Yes" it is *truly* the case that DC has to own this effort - taking it as obvious that DC knows very little about eCommerce at all and that each of 1, 2 and 3 are also obvious truths which cannot usefully be applied to resolve *any* specific issue. More on the specifics below. "This effort" being integration of OpenACS4 with Zope with a view to actually being able to meet requirements of the sort stated by Walter. Specific customization in support of particular customers like Walter can of course be done by anybody competent. He did mention that he was heading off to arsDigita next week, after also mentioning that they want at least $1 million up front for an approach that he regards as inferior to a project led by DC based on Zope using ACS. I don't think he'll have much trouble finding Zope contractors who could do much better than arsDigita (together with arsDigita and OpenACS developers), with that sort of budget. I do think he'll get a less useful result, the spinoffs of which will also be less useful to the Zope community generally, if DC isn't involved in stewardship of the core interfaces. It's clear he knows a lot more about ecommerce and related issues than DC does and isn't particularly worried about that. People with any savvy don't bet their business on, and don't put resources into, open source development based on APIs that are not supported by a steward they can rely on to know how it integrates. arsDigita wouldn't know how to integrate with Zope, but DC should know how to integrate databases with Zope since it already does that and even maintains an Oracle adaptor for that reason. The integration Walter's got in mind is specifically with the Content Management System, which DC should know the most about, though other contractors could also do it well. But if DC doesn't take responsibility for core interfaces, Zope still doesn't have an ecommerce capability, whatever Walter gets. That is obviously not based on sycophantic admiration for DC since I'm saying they are making a major blunder and have copped a lot of shit for saying so. It's based on technical judgment about what is needed for such an integration project after having done some study of the issues. Personally, I'm more interested in the opportunity to talk about requirements with a domain expert like Walter that has such an unusually thorough understanding of both the requirements and some of the architectural issues than in either the fate of DC or the fate of Walter's business. Most of the requirements he stated happen to be useful for many other things. I'll be proceeding to do so if he and the other interesting lurkers that popped up are still around, even though I'm not available as a contractor for this stuff. I would have thought that DC would jump at the chance. Suspect there is just some problem due to current upheavals with change of CEO. Be that as it may I'm not impressed with the sycophancy. It doesn't help either DC or Zope for people to offer rationalizations for obviously dumb positions. As for ignoring the 3 facts. I am responding to you with agreement that these are indeed obvious truths because you are simply stating them as facts that can be agreed on. I ignored them when stated by Paul and focussed only on the specifics because I find it easier to separate issues of merit and "attitude" that way. Repetition of obvious truths, even when not accompanied by overt bristling, merely conveys an attitude of not being interested in the specific issue being raised. That of course is not an "offense" or "foul". However it does inevitably result in people either concluding that there is no point attempting to raise the specifics of an issue when it simply won't be dealt with on it's merits, or else - if it happens to be important enough not to just "get the message" and go away, doing whatever else it takes to make them pay attention. I have no problem with DC's general orientation. I just think they are making a bad mistake on a specific issue against their own interests and Zope's interests and I'm arguing the point. [jimmie] 4. Their consulting projects have not entailed eCommerce. Which leads to their conclusion of priority of eCommerce for them. [albert] A similar point was made by Paul in relation to Postgresql. The self-refutation included in the very same paragraph seems sufficiently generic to answer your point: "In fact, I don't believe we've had a single consulting customer that deployed atop PostgreSQL. You could certainly argue that, since we don't do it, it naturally turned out that way." [jimmie] Paul never stated (from my memory) that eCommerce was an itch that he had and would really like someone else to scratch it. The fact that DC would like or appreciate an excellent eCommerce product for Zope doesn't mean that they have any current needs of one. [albert] Here's the itch and (mildest version of) desire for someone else to scratch it: a) To me - while still "viewing this thread through the lens of hearing "I've got a great idea for someone else to do.": http://lists.codeit.com/pipermail/zcommerce/2001-April/000401.html vvvvvvvvvvvv

I would also guess that there would be at least *some* contracts that DC has *not* gained because the reason the customer wants the sort of things Zope does provide is closely connected with also wanting to charge for various goods and services that go with it and they decide they would prefer to deal with consultants that have a better track record on ecommerce.

Yes, you are correct.

I'm just guessing of course. Only DC can determine whether these, and/or other matters might result in tangible monetary benefit to DC.

Yes, it would be a tangible monetary benefit. One that might likely offset the time invested. Just like a long list of things that DC could do. But we're not a huge company. We've done the Open Source route hoping that folks like you, with a deep passion about a topic, will leverage the work we're doing for free and add to it. ^^^^^^^^^^^^^ No problem with that mild version. Problem as explained previously and below is that I don't believe it can be done without DC ownership or stewardship of the relevant Zope APIs. That's the issue that cannot rationally be discussed until someone at DC has actually evaluated the ACS/OpenACS APIs and is in a position to have an informed view as to what role DC should or should not take in any effort to encourage people to put resources into building on Zope in a way that (incidentally to the people contributing their own efforts for their own reasons), scratches DC's itch for "some" story on ecommerce. Here's some stronger versions of the same "scratch my itch" theme running through Paul's remarks to me so far: vvvvvvvvvvvvv

An entirely separate company has put major resources into an SQL data model that is freely available open source. That saves an awful lot of manpower, just as many companies using Zope have been saved a lot of manpower by the resources DC has put into it.

Agreed. But conversely, if it was so simple, you could have done it in the time it took you to type up these emails. ^^^^^^^^^^^^^^ vvvvvvvvvvvvv

vvvvv

...

What more could a Zope guru want to persuade them to take a look at the possibility of demonstrating how much better that fits with Zope than with java or Tcl?

Manpower. ;-) ^^^^^

Well manpower is one of the major benefits you could get from taking that look.

Perhaps. Perhaps not. Perhaps it could simply be DC doing all the work. Tell me, would *you* participate in the coding of the integration if we took a look? If so, are you interested in doing so *prior* to us taking a look, and confirming that this is a great, easy idea? ^^^^^^^^^^^^ No Paul - I'm not interested in doing any coding of the integration prior to you taking a look. In fact I'm not interested in doing any coding at all, though I did spend a week working on UML models of the OpenACS 3 and offered to spend another 2 weeks and get them done nearly a year ago, with no response. http://lists.codeit.com/pipermail/zcommerce/2000-July/000316.html This time the modelling is a lot simpler for ACS4 - so I've just provided links to the relevant design patterns. Their docs are pretty good too. For a totally bizarre version - "make it easier for me to understand what to do about my itch", see below. b) Responding to Walter as a DC customer known to Paul, here again is the itch: vvvvvvvvvvvvv

It certainly seems to me that ACS is eating Zope's lunch in the market for "serious" eCommerce solutions - and now that the WorldBank is investing so

That's probably true. eCommerce, as is obvious, hasn't been the place we've chosen to compete. But it's hard to be competitive in other areas without some ecommerce story.

much in the ACS through this "Gateway" project of theirs, with no corresponding investments in the Zope world, the trend can only worsen. So it seems to this particular buyer in the market (small potatoes as i am) that incorporating ACS functionality into Zope, instead of just waiting for someone to happen along and fund its development from scratch, is the

Understand, of course, that this applies to *lots* of things. And saying that DC has to eat it out of hide is OK, but there's a limit to how much we can apply that strategy to.

smarter way -- maybe even the only way -- to make it happen. Without industrial-strength eCommerce and all that personalization stuff that goes along with it and is so important to everyone these days, i'm afraid that Digital Creations may be relegating Zope to the prospect of diminishing returns in a market that will just have to expand without significant Zope/DC participation. If this is what you've been trying to tell Chris McD, then i'm afraid i have to agree.

You're certainly right that, if Zope wants to be competitive in eCommerce, then it needs an eCommerce story. The story is a bit murkier for competing in other areas, but it's likely that Zope should have at least *some* production-class story for eCommerce. ^^^^^^^^^^^^^ http://lists.codeit.com/pipermail/zcommerce/2001-April/000402.html BTW I should mention here that the World Bank project is not particularly about ecommerce but about a "Community" system far more to do with "Content Management" - though of course practically any such project is likely to want to be able to take a credit card payment for buying a publication or something like that without being told the only facility available (Wampum) is "pre-alpha". Also BTW, the Wampum docs mention that work on it was sponsored by cash from DC, presumably because they know that and knew that they would have to be the ones to sponsor it if anyone was to come and build anything that needs payment facilities. My view is that they also have to finish it and do several similar quite small things, before there will be much more than prototypes available as a result of other people's work, plus be the ringleader of a fishbowl process similar to CMF if they want other people's work to integrate with Zope, and CMF in particular, enough to give them a "plausible story", as opposed to just a "story" on ecommerce. If it's done right, it could be a "brilliant story" because Zope is ideal for the "Content Management" side developed by DC that has a core competency in that - and already has the necessary facilities to be able to use SQL built by others with a core competency in ecommerce and related SQL. Walter, one of DC's customer's, has a clear understanding of that but DC doesn't. They might want to consult him as a source of expertize on what could be useful to them in the market. I certainly do (but I won't be offering to pay ;-) [jimmie] Anybody who uses Zope for website development receives monetary value due to the fact they did not have to pay for Zope or any other web app software. DC is a benefactor as such and not the beneficiary. If DC were the sole beneficiary of Zope, there would be no community, no one else contributing, no one else advocating, no one else desiring for ... Anybody who has sufficient need of an eCommerce product and builds it themselves in Zope is a beneficiary of building on the foundation of Zope. [albert] Fine. Some people have already been doing that and I have no doubt that work will end up scratching more than their own itch if DC takes responsibility for what *it* needs to do. Until that happens I do not believe this will result in anything that can be widely deployed enough to make a real difference or to scratch the itch that DC does have for an ecommerce story. As evidence I cite the fact that it hasn't happened so far. That ought to be sufficient for serious interest in discussing what else might be needed. [jimmie] OpenACS is a testimony to the fact that "ownership" by the "creators of the tool"TM is not necessary for success. OpenACS is a success in spite of not due to arsDigita's stewardship. [albert] There are many highly successful free software projects and some open source projects that are not dependent on stewardship by any particular organization (though often a defacto stewardship by some individual or small group within the wider developer community is critically important - often known as the "core team" and in at least one case as the "benevolent dictator for life"). Larger projects simply cannot do without it due to obvious needs for architectural integrity and stability in APIs. OpenACS is a spectacularly bad example for your point. It has been *completely* dependent on an ACS core developed essentially in-house by arsDigita and simply released under GPL without any significant "developer community" involvement at all. Up to now OpenACS has simply been *porting* SQL to a different dialect and have been severely hindered in that by lack of influence on decisions by the stewards that could have made such porting easier. There is nothing to port and therefore nothing for OpenACS to be successful in porting other than the ACS itself developed by arsDigita as stewards. Very little has been added, though much more will be now that the main hurdles are being overcome. Within OpenACS, porting of the "kernel" is entirely dependent on work currently being done by a core team of 2 or 3. An impressive team of developers for the rest of the ACS "core" is currently lined up at the starting gate with the obvious technical necessity of the core team deciding what has to be done undisputed. Only after that, and based on it, will it be possible for others to actually use and build on what the stewards are responsible for. (I'm not sure how much has been added by users of OpenACS 3 in using the core or how much has been added by the users of ACS 3, but the core itself depends on the stewards). Assuming that ACS really does want database independence, I would hope the OpenACS porting work would be folded back in to ACS (it has been designed to support *both* Oracle and Postgresql and any others that people wish to do the porting for). There would then be some complex issues about stewardship and avoiding a damaging fork will depend on the wisdom of the stewards. This whole area is murky at present as OpenACS is centered on AOLserver/Tcl whereas ACS has abandoned that for a java platform for the next major release, ACS 5. One thing it highlights however is the essential independence of the SQL for which arsDigita is undoubtedly the current steward, from web application platforms that might use it (along with other things they do), such as AOLserver/Tcl for which OpenACS is now the current steward, and Zope for which DC could be the steward. If Zope did integrate the OpenACS4 SQL and DC attempted to fork it, that would be a flop. They are not its steward and do not have the capability. [jimmie] There have been several consulting companies built up around ACS/OpenACS without requiring blessing from arsDigita. Rather than see DC go out and commit resources on eCommerce which apparently does not currently impact any of their consulting gigs. I would rather see them improve core Zope and continue on what they have invested their knowledge and skills in. [albert] There may be several built up around Zope too. But neither they nor the open source community built around Zope have more than a "voice" in the clear stewardship of the Zope core by DC. DC is certainly far more serious about putting actual resources into involving a wider developer community than arsDigita. But it is quite clear who is in charge of the core. Without somebody in charge of it there would be no core to build on and that somebody is DC. BTW while I agree with RDM's remarks "in theory". I don't agree it is actually a correct response to Walter's earlier comment: http://lists.codeit.com/pipermail/zcommerce/2001-April/000431.html a) There is of course no question of DC prohibiting anyone from developing anything based on Zope - and they have made it clear they would be delighted if somebody else developed ecommerce etc. b) As stated in jimmie's fact 2, it is also clear that DC would cooperate with any necessary changes to the Zope core. (I'm not aware of any that would be needed for the sort of things that Walter is looking for, but even if there turn out to be, there's no reason whatever to expect anything but cooperation). c) It's true that if DC dropped Zope or tried to do something bizarre there are enough skilled developers around to be certain that it would continue being maintained - which is a lot more reassuring for users of open source software than for most commercial software - including stuff from big companies. But DC isn't just the biggest consulting firm using a product that they happen to have developed as RDM seems to be suggesting. They are also the main developers and anyone proposing a fork would just be laughed at. (Which of course also doesn't prevent anyone developing specialized variants or using bits of Zope like ZODB independently). Customers like Walter who want major enhancements added to Zope, could certainly get them done elsewhere if necessary, but it would take longer, cost more and be generally less satisfactory than if project management was done by the people who know it best. So he was being quite realistic in saying that if DC says Zope isn't for ecommerce, there wouldn't be much point him arguing. Once a toolkit is available people who want it specially customized can certainly go to any consultants they like (though DC will still have a "natural advantage" in being perceived as the most likely to do a good job). But Walter is looking for a system based on Zope plus ACS and is already a customer of DC. He wrote an extremely perceptive analysis showing a thorough understanding of both his own needs and the strengths and weaknesses of both ACS and Zope, explaining why he wanted a combination of both. http://lists.codeit.com/pipermail/zcommerce/2001-April/000418.html In that he also referred to thoughtful contributions that had been made by others on the subject (no I'm not referring to the fact that he was agreeing with me, though that is so unusual it may perhaps color my view of him as a very perceptive person ;-) - checkout that particular message and then look at his others and those he referred to from the other lurkers that spoke up at the same time. The CMF is an "application" built on top of the Zope core, which can itself work with other applications and applets. It didn't happen just because DC needed it. They did need it and they put significant resources into making sure it happened. Others no doubt contributed to that and others will certainly build on it. The issue is whether there is anything similar (even though much smaller), in relation to ecommerce that DC would need to invest their knowledge and skills in for others to also be able to do so and whether DC should decide to do that. That issue can only be resolved by DC and so far they have not taken the necessary minimal steps in order to be able to find out. A rational explanation for that would be if jimmie's view that they have no such itch was correct. If they don't need it and any benefit to them would obviously be far lower in priority than other pressing concerns, there is no point even thinking about it. Since that doesn't appear to be the case from Paul's explicit statements, I would regard any such decision as irrational. DC has to make it's own decisions about what it will commit to, regardless of what either jimmie or I or anyone else may want. But I would certainly agree that it would be a bad move for them to get into developing (essential) SQL for industrial strength ecommerce, personalization, workflow etc when: a) They have no core competency in that area b) An open source solution that they can just plug into is freely available. But that isn't what they are being asked to commit to. Checkout the interaction with a DC customer right before our eyes in this list and it's pretty obvious that DC does have an itch. It's losing existing customers without taking into account the obvious facts about what "Content Management" is often used in connection with and the known facts about customers who also have related ecommerce (and/or "personalization" or "collaborative filtering") needs and decide to go elsewhere because of that. Paul has explicitly confirmed my "guess" that this would be the case. Here's the example that happened right here, immediately following above quote from Paul: vvvvvvvvvvvvvv

You're certainly right that, if Zope wants to be competitive in eCommerce, then it needs an eCommerce story. The story is a bit murkier for competing in other areas, but it's likely that Zope should have at least *some* production-class story for eCommerce.

For personalization, depends on you definition. We might alread have some of it.

Whaddya got? I've still got my ears on... |/|/

But concerning the remedy...is it *truly* the case that DC has to own this effort? After all, many of you know more about eCommerce than us. We definately should participate, though.

--Paul

You certainly shouldn't be going it alone, Paul. Without the interest of both the developer community AND business people in search of solutions, this effort would likely not succeed. But, presuming for a moment that the subscribers to this list could muster enough developers and business solution-buyers to warrant it, might you be willing to dedicate project management and technical expertise enough to do a proper opportunity analysis? IMO, unless DC is serious enough about this issue to make at least that sort of commitment, this worthy project is probably a non-starter. ^^^^^^^^^^^^ http://lists.codeit.com/pipermail/zcommerce/2001-April/000408.html It's as simple as that. Unless DC is serious enough about this issue to at least be willing to do a proper opportunity analysis, it is probably a non-starter. [jimmie] Someone with the need and skills for eCommerce should steward this project. DC has already provided the forums and resources (ZWiki, fishbowl, etc.) to permit someone to get this going. DC contrary to arsDigita has been much better at stewarding it's community. [albert]

From what I've seen DC has not only been much better at encouraging an open source community than arsDigita (which wouldn't be very difficult), but also has an exemplary record in that respect.

So why hasn't anyone stepped forward to steward such a project? Clearly it isn't the absence of forums, Zwiki and fishbowl. These need not be provided by DC either. There's also a Zcommerce mailing list and at least 3 individual projects. Something must be missing or it would have happened. I'd suggest what's been missing is DC *active* interest and encouragement on that *specific* issue. [jimmie] I too would like to see eCommerce well supported. The website I am currently working on will require such. When I get to that stage of development, if one isn't available, I won't badger DC, I'll build what I need. If it is good enough to contribute it back. I'll do so. [albert] Fine. That will make four. It still won't have happened. Whatever is missing will still be missing. [jimmie] DC has been honest and forthright about this. They have given answers. Don't badger them because the answers aren't what you wanted to hear. They may be close to DC (Washington DC) but they aren't politicians. :) If anyone here has unlimited resources (unlike DC), please contribute, hire DC. I'm sure Paul (oops, just read the PR, maybe this should be Brian) would be more happy to recruit more Pythoneers to work towards building a better Zope. [albert] No problem with Paul's honesty or forthrightness. Problem is that Paul has honestly and forthrightly confirmed he hasn't a clue as to what needs to be done and honestly and forthrightly" demanded that someone else solve *that* problem: vvvvvvvvvv My gosh, functions and triggers in Python?!!? OK, Albert, score one for you! :^) Thanks for bringing that on our radar. I'd like to emphasize that Albert's idea has merit. We'd like to learn more about the idea, as we don't know as much as we should about it. But someone needs to make it easier for us -- unfortunately, it's just reality that we don't have as much time to investigate possibilities as we would like. ^^^^^^^^^^ http://lists.codeit.com/pipermail/zcommerce/2001-April/000405.html What the *fuck* am I or anyone else supposed to do, to make it "easier" for DC to know as much as it should about an idea Paul thinks might have merit, than spell it out as to where to send someone to take a look? Fred asked for tips so I repeated the original URLs for him. They did get buried in the thread long before Fred could have been expected to have seen them. I'm not expecting a reply "please make it easier for me to click on these links". http://lists.codeit.com/pipermail/zcommerce/2001-April/000429.html (BTW thanks to Michael Bernstein for rescuing the original posting from the obscurity in which I jumbled it with other matters that I am actually more interested in. He is not to blame for the consequences ;-) In case an "executive overview" is needed I also supplied (later) this. vvvvvvvvv A good starting point for understanding what ACS does along these lines is Philip Greenspan's online book (also available as an elegant coffee table edition for the suits, with the same stunningly beautiful and irrelevant photos ;-) http://www.arsdigita.com/books/panda/ Especially chapters 9 and 14. The whole book is also necessary reading for a serious study of what ACS is (or was) about. ^^^^^^^^^^ http://lists.codeit.com/pipermail/zcommerce/2001-April/000413.html If DC's investors need powerpoint slides to authorize a week's time on checking out whether something like this might be worthwhile, they should get some new investors. Things are pretty grim for a lot of open source businesses and are likely to get worse. http://news.cnet.com/news/0-1003-200-5112816.html But if DC hasn't got the resources to spend a week out of pocket investigating whether it could meet Walter's requirements, it probably has a legal obligation to file for insolvency. On a any reasonable sort of contract that much work is usually done out of pocket just in bidding for it. I don't need Paul's "blessing" as to whether "Albert's idea has merit". I'll close with the final words in his previous response to me: "I suggest you participate, rather than pontificate." [jimmie] No offense intended towards anyone here. I just wanted to state my opinion on DC and on this matter. I have been a long time member of this community, since it was a Bobo list, before Zope was open sourced. Jimmie Houchin [albert] None given and none taken. Any vehemence is in summarizing as your perfectly reasonable post provided an opportunity to do so. I'm not a member of either Zope or OpenACS communities but have been lurking for quite a while (since your suggestion to do so in fact ;-) If anyone wants to take offence, that's entirely up to them. It would be more useful to respond to the arguments, and even more useful to just respond to Walter's requirements. I'm not planning to badger DC any further on this. Included in the current links I provided for Fred are also links to the stuff I posted nearly a year earlier: http://lists.codeit.com/pipermail/zcommerce/2001-April/000429.html I haven't bothered them since, until now, and I've said my piece now. Not really interested in further discussion of DC. Am interested in discussion of technical issues for ecommerce, collaborative filtering, workflow etc, and on Walter's requirements and the points raised by others that joined in on that. Now back to Walter's stuff, when I get some sleep. http://lists.codeit.com/pipermail/zcommerce/2001-April/000418.html

On Thu, 5 Apr 2001, Chris McDonough wrote:

To address the rest of your mail, I don't doubt your experience nor do I think that having a Zope "ecommerce story" is a bad idea. My problem is understanding how it's possible that DC *needs* to do this. Do you think we're just a bunch of guys sitting around without a plan who need to have some structure put in to our lives or what?

Out here in the portland office, we just sit around drinkin chardonay and smokin' fatties all day long. I thought that was the plan. You guys have a plan? Cool! -Michel

We contribute to Zope because making zope better makes our own businesses better. Direct return. DC has the same motivation, no more and no less.

Amen to that :-) Chris

[fred] On Thu, Apr 05, 2001 at 07:45:49AM +1000, Albert Langer wrote:

There's nothing much that could or should be "ported" in the OpenACS Tcl. All DC needs to do is standardize python/Zope interfaces to the underlying SQL engine (I don't mean DAs to the database engine, but a Zopish replacement, not port, for the fairly thin layers done in Tcl).

At last, an actionable statement. (I've long been intrigued about using the ACS data model from a Zope front end, but all the whinging on this thread is enough to sour one on the idea.) Although I messed around with ACS3 a while back, I don't understand the scope of what you mean by "the fairly thin layers" that need to be standardized. Could you refer to some specific Tcl code in the ACS core that encompasses this layer. [albert] At last an actionable response. No need for me to whinge about the lack of one ;-) My advice would be to forget ACS3 completely as that's the official ACS recommendation and it's much harder to disentangle the actual database API from the Tcl line noise. ACS4 is a dramatically different system with a clean API and much more object oriented. The core of ACS consists of a kernel data model mainly accessed directly by the other core modules. I'd study the sql for that first. All modules now work through a small set of Tcl database api calls that could fairly easily be replaced. Most of them have a fairly thin layer above that. To understand the scope you'll need to go look at it. *Much* easier than for ACS3, and greatly simplified by the approach to porting with a Query Dispatcher (and SQL extractor) used by OpenACS. Note that the initial kernel only just released for internal OpenACS development and core modules will be a while. But could take that long to get familiar with what both ACS4 and OpenACS 4 are all about, so start catching up now to be able to use it when it's ready. [fred] I'm currently doing some simple community websites using Zope and I've borrowed from ACS to build "user" schemas (in PostgreSQL) that underlie a LoginManager front end. It's tempting to move on from that basis and build additional features into the sites using a similar scheme of Zope front-end to ACS data, and I'd like to explore Albert's idea of an interface layer as opposed to direct Z SQL Method access of the data. [albert] Definately the way to start! Note that the "user" schemas are now *heavily* dependent on the kernel with group memberships etc generalized into handling all kinds of relationships and permissions built into kernel. There is of course much more needed but I'd say head on down there and start looking at it now before discussion of that. Please note that I am not even a participant in OpenACS project. Get any further advice from people who actually know by joining the OpenACS bboards. Make sure you read their bboards first and then ask any questions there. cvs address is mentioned within the bboards ;-) Use that cvs - not the downloads from arsDigita (there are no downloads from OpenACS yet). I *strongly* recommend reading the docs *before* getting bogged down in the Tcl - and work from the OpenACS version *not* the original ACS version. Also read about the Query Dispatcher first and checkout the python automatic extractor for the SQL. Current version of extractor is at: http://sindev.dyndns.org/openacs-tools.tgz But has not been announced yet and will probably be replaced tomorrow. This will make porting for both Tcl and python versions much easier. (In general, ignore *anything* said by Chris when claiming to interpret anything I am saying. Also I'd recommend not saying much about Zope as Chris was there nearly a year ago and the impression he left was distinctly unfavorable.) Here's the relevant extracts from my original posting buried among many other things, with URLs: vvvvvvvvvvvvvvvvvv ACS 4 provides an Oracle based web application server framework with LDAP integration. The kernel has a finely grained permissions system, with a role/party/group framework compatible with the "Accountability" pattern and an object model compatible with the "Domain Object Model" pattern. This is very appropriate for a sophisticated LDAP directory backend (as well as being necessary for the industrial strength RDBMS essential for serious Zope ecommerce). http://developer.arsdigita.com/doc/kernel-doc.html http://www.martinfowler.com/ap2/index.html http://www.martinfowler.com/apsupp/accountability.pdf http://st-www.cs.uiuc.edu/users/johnson/DOM.html ACS4 also provides an excellent workflow engine: http://developer.arsdigita.com/doc/acs-workflow/ This can add the missing "strategy" side of the Domain Object Model together with Transwarp. Zope can provide much better UI and management stuff to work with the engine. It can also be a basis for reliable distributed workflow/transactions/replication: http://www.distribution.cs.ncl.ac.uk/projects/WorkflowSystem/index.html This is a better approach for some types of database replication than that currently proposed for ZEO or the usual approaches described in Chapter 8 of: http://research.microsoft.com/pubs/ccontrol/ ACS4 is being ported to PostgreSQL by OpenACS which has previously ported ACS3: http://openacs.org/4/ http://openacs.org/bboard/q-and-a.tcl?topic_id=12&topic=OpenACS%204%2e0%20De sign Initial version of kernel already out. [...] BTW, while I'm at it with all the links above, I'd like to draw attention to some earlier postings re the need for Zope and ACS to combined for viable ecommerce: http://lists.codeit.com/pipermail/zcommerce/2000-June/000265.html http://lists.codeit.com/pipermail/zcommerce/2000-June/000259.html http://lists.codeit.com/pipermail/zcommerce/2000-June/000257.html Right now arsDigita is going through a major upheaval and it looks like OpenACS will provide an umbrella home for various ports of ACS 4, including python/Zope as well as their main orientation to Tcl. The data model of ACS4 is now much better separated from the Tcl side and they are doing a Query Dispatcher for supporting multiple RDBMS ports (with some tools in python for extracting SQL from the Tcl code completely ;-). http://developer.arsdigita.com/commerce-project-central/ http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg%5fid=000b5M&topic%5fid =web%2fdb&topic= http://www.arsdigita.com/bboard/q-and-a-fetch-msg?msg%5fid=000ZGz&topic%5fid =web%2fdb&topic= A Zopista involved in OpenACS has mentioned working on port of data models of ecommerce module. That could result in a Zope port if there is active support from DC. http://openacs.org/bboard/q-and-a-fetch-msg.tcl?msg_id=0001AP&topic_id=12&to pic=OpenACS%204%2e0%20Design At the same time there seems to be some problems with an AOLserver fork that could result in greater interest in using Zserver (don't know much about that - just speculating). If June 2000 was "premature", perhaps this is a better time to hope for some serious DC interest both in enabling an industrial strength ecommerce and workflow system for Zope [...] ^^^^^^^^^^^^^^

On Tue, Apr 03, 2001 at 11:27:41AM -0400, Paul Everitt wrote:

...

A third open source community has put major resources into turning postgresql 7.1 into an industrial strength RDBMS quite capable of replacing Oracle in many situations, which is also about to get python as a built in backend procedural language.

I hadn't heard that Python was going to be a stored procedure language for PostgreSQL. Can you send me a link?

Google gave me the following reference: http://www.postgresql.org/mhonarc/pgsql-hackers/2000-08/msg00432.html -- Martijn Pieters | Software Engineer mailto:mj@digicool.com | Digital Creations http://www.digicool.com/ | Creators of Zope http://www.zope.org/ ---------------------------------------------

[Martijn] On Tue, Apr 03, 2001 at 11:27:41AM -0400, Paul Everitt wrote: [Albert]

...

A third open source community has put major resources into turning postgresql 7.1 into an industrial strength RDBMS quite capable of replacing Oracle in many situations, which is also about to get python as a built in backend procedural language. [Paul] I hadn't heard that Python was going to be a stored procedure language for PostgreSQL. Can you send me a link?

[Martijn] Google gave me the following reference: http://www.postgresql.org/mhonarc/pgsql-hackers/2000-08/msg00432.html [Albert] No further work was published on that since August 2000 until a few days ago when a Postgresql 7.1 version was made available (31 March): http://users.ids.net/~bosma/plpython-310301.tar.gz Not sure whether it has been announced yet - author still planning better build integration plus handling of imports and postgresql vectors/arrays. Some significant features (to me) are: 1) Any arbitrary cPython module can be imported - though currently the list of permitted modules is statically compiled into the restricted environment bastion. 2) A dictionary SD is available shared among all calls to a function and another GD shared among all calls to any function. Both are per connection/backend and know nothing about statements or transactions. 3) Arbitrary SQL (which includes calls to other procedures including other procedural languages) can be prepared and executed separately within a function. This means it can work with the same efficiency of pre-compiled query plans as the "native" plpgsql procedural language. Should be possible to prepare the queries for an application after opening a database connection and then just reference the query plans via SD or GD. This is vastly more efficient for industrial strength databases that have serious query planning than the usual approach of just feeding the original SQL for parsing and query planning on each access. Looks to me like it's a significant advance compared with Oracle's embedded java. Combined with Postgresql's abilities to create abstract data types, operators, aggregates etc and it's incredible "Rules" system that effectively gives completely writable views on composite objects, with complex logic, this should be dynamite. BTW it was published following Oleg Broytmann's passing remark around 19 March in: "RE: [Zope] Re: [Zope-Annce] Localized DateTime classes" "PS. [offtopic] Did you see my question on Python in Postgres backend?" I did a quick search through Zope archives and found nothing, so wrote to Oleg for more info as I'd been wishing for such a thing and hadn't heard of one. He promptly provided some leads from an email reply from Hannu Krosing and I tracked down a list of about half a dozen people who had expressed interest in this at one time or another and fired off an email suggesting that and another unfinished attempt should be taken up as a Project to get the job finished (also BCCs to 1 staffer each at Zope and Active State in view of potential importance for them). Got a prompt response from Andrew Bosma (author of above), promising to finish it in a week or so, which he then did. (Aside to Tom Jenkins - he didn't seem to be at all insulted at my suggestion, despite my explicitly mentioning that I lacked the C and Postgresql skills to offer any help at all). I think I'll wait more than my customary 24 hours before responding to the rest of Paul's messages and also delay responding to Walter as that overlaps with responses to Paul. But I'll respond now to one item as it directly relates to above. [Paul] I'm not sure how much consulting you've done, but from what I've seen, people don't change database infrastructures because there's a new one that's free. Perhaps *new* customers will choose the free one, but that's a long-haul proposition. If you haven't, then read "Crossing the Chasm". Your arguments appeal to the early market, but scare the hell out of the mainstream market. It takes time for new things like Python, Zope, the ZODB, and PostgreSQL to penetrate the mainstream. Besides, you've lost me here. Is the goal to gain e-commerce (whether from OpenACS, RedHat Interchange, or some other solution), or is the goal to sell PostgreSQL to our consulting customers? [Albert] My impression is that Oracle shops tend to be stuck with Oracle for much the same reasons that Microsoft shops tend to be stuck with Microsoft etc. These things change over time and there are signs of significant changes concerning mainstream databases - eg when SAP recently released sap db (not the SAP applications) as open source, they mentioned that they thought databases were now pretty much a commodity infrastructure, which seems odd in view of Oracle's licensing fees - but they did do it - with some 200 staff still deployed on maintaining it. Certainly there isn't much DC can do about that as your core competency lies elsewhere. But the area you are in with a web application platform (sometimes) requires an RDBMS (eg for ecommerce as opposed to content management), for 2 quite different reasons: First, for integration with internal systems. For example the arsDigita ecommerce requirements documents indicate that they have no intention of doing much work on fulfilments or inventory or accounting because these just aren't what they know about so the integration with internal systems is done better by others (though they do of course provide the interfaces and database adaptors to be able to connect). For that, you certainly need Oracle and other mainstream adapters (insofar as you need more than ODBC), and the customers are stuck with having to buy whatever additional Oracle licenses they need to handle whatever additional volume their internal systems have to cope with as a result of ecommerce. A related issue is that even given the licensing fees for Oracle, there's an awful lot of SQL applications code and tools that won't just transfer smoothly to Postgresql's dialect, so despite now being rock solid and in many ways superior, there are still some rational arguments for preferring a mainstream RDBMS when you are *not* doing something more or less self-contained but needing a general purpose database platform for numerous projects. (This problem is greatly reduced by increasing SQL92 compliance of Postgresql and especially availability now of outer joins). It isn't just a matter of "new" customers, but what the DBMS will actually be used for. There's a second reason for needing an RDBMS despite the great strengths of an OODBMS like ZODB for content management and many other aspects of a web application platform - there are some things that work much better with an RDBMS - especially for online ecommerce. In my view it just doesn't make sense to handle standard order processing and financial transactions in an ODBMS - especially one aggressively optimized for reads rather than writes like ZODB. Whether that view is correct or not, the idea of doing so "scares the hell" out a lot of people who are used to being able to enforce certain business rule constraints, auditing policies etc in database schemas they can understand rather than trust to whatever the application programmers are up to, and need reports and OLAP as well as OLTP. So rightly or wrongly, an ecommerce platform that doesn't use an RDBMS for that will have great difficulty crossing the chasm. Furthermore, an ecommerce platform that doesn't use a mainstream RDBMS for that will have great difficulty too, although in my view for "fud" reasons rather than good reasons since a commerce server *is* far more self-contained and only needs the ability to *interface* with internal systems rather than replace them as a general purpose DBMS. Now where's the disagreement. Well, this is one of the things that makes recent developments with ACS and OpenACS so interesting. With ACS4, arsDigita has done, (for other reasons), the minimum necessary separation of a proper database API that makes it much easier for OpenACS to port to Postgresql. Instead of just doing an easier port to Postgresql, OpenACS has decided to support *both* immediately and would also like to be an "umbrella" for ports to other databases. If someone were trying to cross the chasm with a "whole product" solution, they would need to cover the "whole" of the online order and payment processing as well as catalog display etc as an integrated solution that can interface to internal systems. But the natural interface is with internal fulfilments (also done online for some things) and inventory and accounting etc - not with separate internal systems for order and payment processing since online orders and payments are significantly different and need integration with the web platform far more than with corresponding internal systems for other types of orders and payments. Having a solution that can *either* provide "reassurance" that their existing Oracle DBA and developer skills can be applied *or* offer a dramatically lower total cost of ownership plus the increasingly recognized benefits of open source with Postgresql for the web backend (as opposed to internal system interfaces), can *only* be an advantage. Especially when both the data modelling and SQL for that has been done for you elsewhere and is freely available. Demonstrating that you can also offer some add ons with the Postgresql version leveraging your python skills in the backend as well as in the web platform, that are far more difficult to do with java solutions, should also be a selling point - not for Postgresql but for what *you* can be consulted about (and for what your customers might think they can maintain and extend further in house with a simple scripting language rather than heavy weight java development). The *way* that OpenACS has gone about supporting ports for multiple databases is also important. They are using a Query Dispatcher to select dialect specific SQL for the configured database so their Tcl API is effectively database independent. (SQL phrasebook or Library pattern). This can largely separate the SQL porting work from the actual web application server and makes it dramatically easier to port to Zope. An automated SQLextractor tool is being developed (in python ;-) for collecting the embedded DQL and DML mingled with Tcl and re-writing the Tcl to get it from the Query Dispatcher instead. As Randall just mentioned, Postgresql is an ORDBMS not just an RDBMS. Now with a "cool" python stored procedural language (which does *far* more than just triggers). Looks to me like a perfect complement to Zope - especially since you already have a transaction manager that can distribute transactions across both internal ODBMS (ZODB) and ORDBMS (Postgresql) and "legacy" external RDBMS (like Oracle). If you've been managing to cross the chasm in the Content Management area using non-mainstream technologies like python and ZODB, I think you could do rather well in other areas as well with a python enabled ORDBMS that seems a perfect complement to ZODB plus what OpenACS has to offer. The metadata/operational separation in the ACS kernel is also *very* complementary to Transwarp. BTW in case I am giving the wrong impression, ecommerce as such is far from being central to what ACS does (they haven't even released the ecommerce module for ACS 4 java yet, though the skeleton framework plus workflow engine points to something very interesting about to happen). ACS stands for the arsDigita *Community* System. They understand a *lot* about the relationship between ecommerce and building an online community that fits very well with Zope's approach to content management. What they do isn't adequately described by "personalization" and it does need an RDBMS rather than an ODBMS aggressively optimized for reads over writes. (Their tuning is for a high ratio of queries to updates as with any web service, but they do a *lot* more tracking than is feasible with ZODB).

Hi Albert, Coupla points: 1. It takes serious stamina to read a post that long, you might get more readers if you cut it down to a few key points. 2. I suggest you read The Cathedral and the Bazar by Eric Raymond (I think it's living somewhere on tuxedo.org(com?)) to find out how open source works best. 3. You obviously seem very dedicated to your cause. Try and channel this into forming relationships with people who may be able to help you rather than trying to beat them into your way of thinking ;-) cheers, Chris (who's probably posted far worse in his time but is trying to learn his lesson ;-)

On Wed, 4 Apr 2001, Marc Fischer wrote:

in an dtml-in tag I want to sort by different aspects. But how?!?

I only know how to sort by one like this:

sort=title ....

sort="title,date,id" I put a big patch for dtml-in into Collector for more elaborate sorting. There is also a product called Zieve. Oleg. ---- Oleg Broytmann http://www.zope.org/Members/phd/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.

[...] [Tom Jenkins] Lets look at it another way. I'm pretty sure I know what you would you say if I said "Hey Albert, I would really like to have some monitoring stuff built in to zope. You really should do this for me." (Note to Paul: I haven't seen your fishbowl proposal for monitoring posted on dev.zope.org yet... guess _I'll_ have to write one, sheesh!) [...] [Albert] Not sure what you are referring to re "monitoring" (and not interested in the rest of your message). If it's what I think you might mean, I'm pretty sure I would say that I have been working on an async AgentX/JIDM agent for remote monitoring (and management) of python applications and may have something to contribute. So if that is relevant, please drop me a note if you do write such a proposal.