R: R: [Zope-DB] ZODBCDA for Python 2.3.3
phil at xfr.co.uk
Fri Apr 2 08:43:46 EST 2004
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.
>>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
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...
More information about the Zope-DB