R: R: [Zope-DB] ZODBCDA for Python 2.3.3

[Philip Kilner]

Hi Charlie,

Charlie Clark wrote:
> Marc-André is currently very busy with other things at the 
> moment; repairing his Lear jet!
>  

I have a bicycle I can lend him if he's having trouble!

;-)

>>*However*, I would not have found Zope an approachable product without
>>the free ODBC driver - IOW, if there had /never/ been a free/bundled
>>ODBC driver, I would not be using Zope in the first place.
> 
> We are aware of this through the enquiries we receive about mxODBC. The 
> reason behind things being the was they are is historical.
>  

Understood.

>>I think this problem needs solving not so much for us as for those who
>>may follow us. I'd hate to think that Zope's uptake could be slowed down
>>by this omission, but I'm pretty sure that's what will happen - although
>>I have no basis for judging the scale of the problem.
> 
> We disagree here. Anyone can get an evaluation licence for mxODBC for free. 
> Anyone who's serious about development on this basis is usually able to 
> justify the licence. mxODBC opens doors to developers and not just on the MS 
> Windows front.
>  

Perhaps a few words about my background might flesh this out a bit.

I am emphatically /not/ a coder (as you must realise from some of the 
help you have given me in the past!!!), but rather an application 
developer. I see myself as stringing other people's pearls most of the time.

My approach to application development is based on two things: -
- A skill set oriented to formalising requirements and business rules, 
and expressing these in an RDBMS.
- A background using development tools with a minimum of abstraction 
between the developer and the application (end-user RAD tools, if you like).

After many years developing RDBMS-driven solutions, I ended up as the 
Technical Director of an e-Commerce company with a proprietary script 
engine - it was whilst analysing the competition that I found Python & 
Zope. Python was opaque to me at the time (although clearly a better 
engine - with a better license - than ours), but in Zope I found pearls 
I could usefully string...

I have some concerns about Zope and it's direction - tools like ZPT and 
the dropping of ODBC support would make it much, much, harder for 
someone like me to get up to speed with Zope. I don't know how many 
people that is - but it's an audience which could potentially be lost to 
Zope. It should be easy to knock up a basic UI for an RDBMS back end in 
Zope, but it's not easy /enough/, and it's not as easy as it /could/ be. 
I'd like to be able to say "don't use Access, use Zope" - but first I 
have to write the docs that address that audience, which is proving hard 
work...

People in that camp are not "serious about development" /at all/ - they 
just have a job to do, and will pick away at tools until they find one 
they can fly. I'd like Zope to continue to be an option - clearly it's 
not an end-user tool, but it should be something a "para-techie" can 
usefully get to grips with, I think.

I'd be interested in anyone else's views on the above.

>>- Would eGenix consider releasing a free driver without the qualities
>>that made the eGenix product superior to the ZC product in the first place?
>>It doesn't seem like the best route, simply because the eGenix driver
>>wasn't written to have such deficiencies!
> 
> In answer to both of these it's important to note that it's not really the 
> mxODBCZopeDA that is the issue but the mxODBC python driver which is 
> included. This requires a lot of work to maintain and support; we have to do 
> implement workarounds to deal with known problems with the various RDBMS 
> ODBC drivers out there. Unfortunately there seems to be a 100% correlation 
> between users who are prepared to pay for a licence and those who are 
> prepared to pay for support and with the converse being the case (if licence 
> == free: support = free) is a real disincentive for providing a free 
> version. At the end of the day it is customer satisfaction that is the most 
> important thing for our strategy and we get far more "well done, thanks for 
> a great product" than "I wish I'd never bought this lousy thing" comments. 
> We are going to continue to try and keep these people happy.
> 

Understood, and I did not think it was a goer, for the reasons you 
articulate and more.

Re. support (theoretical given the above), it would /have/ to be 
community supported. I use the Mercury/32 mail server (From David 
Harris, the guy who wrote Pegasus), and this works in the same way - 
free product, commercial support available at cost, list support from 
community. Not sure we'd have the critical mass for that anyway...

> It should be noted that commercial parts or implementations have always been 
> part of Zope. DC/ZC has always kept some inhouse developments to themselves; 
> there is a commercial version of Plone; there are other commercial products. 
> We think that this is indicative of a healthy market in the Zope world. 
> Everyone benefits from this dual approach and it should be noted that the 
> *free* libraries such as mxDateTime are used in lots of products including 
> many ZopeDA's
> 

Agreed and understood.

Hope this better explains my PoV...

Cheers,

PhilK