October 1999 - Zope-Dev

Re: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
by M.-A. Lemburg 12 Oct '99

12 Oct '99

Christopher Petrilli wrote: > > > Christopher Petrilli wrote: > >> > >> BTW, I didn't mean to imply that what you've done isn't useful, it's simply > >> incompatible with the direction we're taking. This is somewhat discussed in > >> my roadmap. If you'd like to maintain the interface that you're talking > >> about, then that'd be excellent. > > > > In what way is it incompatible ? mxODBC is DB API compliant in most parts > > and has lots of useful extensions such as the ODBC catalog functions. The > > interface itself is thread safe and thread friendly. Of course, whether > > a certain ODBC driver is depends on the driver. > > We are abandoning the use of DB-API interfaces for our own use simply > because they have proven to be of little value in getting things running. Why is that ? The DB API is intended to be of general use, how can Zope be so much different ? > In addition, their behavioral assumptions are sometimes quite incompatible > with Zope requirements. Jim Fulton can better speak to this. We're now > doing a more "thin shim" approach, and not going anywhere near the DB-API or > SWIG. Oh well, then I guess you're on your own. I would have rather liked to see more native DB-API style interfaces appear than incompatible thin layer new ones. > > FYI, mxODBC currently works with these database drivers/managers: > > Adabas - Informix - MySQL - PostgreSQL - Oracle - Solid - > > Sybase - Windows ODBC Manager - Unix iODBC Driver Manager - > > Linux unixODBC Driver Manager - EasySoft ODBC Bridge - > > OpenLink ODBC drivers - Intersolv ODBC drivers > > + virtually any database supported by one of the listed ODBC > > managers. > > The issue is more that in many cases (Oracle for example) ODBC is enormously > slower than the native drivers. we've had people comment that it's > something around an order of magnitude. Also, Oracle's ODBC drivers leak > like the proverbial sieve. The problem with Oracle is that the connection times are exorbitant. Once you are connected the performance is much better. Also there are several different drivers out there: the original one by Oracle, the one by MS included in their free ODBC driver kit, ones by OpenLink and InterSolv. ODBC is not really all that bad -- at least not always. It gives you database flexibility and portability that no other standard has achieved over the years, not even the later ones pushed by MS. > Therefore we plan to target native interfaces, > rather than glued on top constructs. Only on Windows is ODBC any form of > gain. Now, if X/Open CLI is the native interface (as with DB2), then this > will be fine... we just plan to talk to native interfaces. FYI, Solid also uses ODBC as native interface. (BTW, I finally got the combo IBM DB2 / mxODBC to link without core dumps. Now I'll have to dive into configuring the DB2 database...) -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 80 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0

Re: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
by Christopher Petrilli 12 Oct '99

12 Oct '99

> On Tue, 12 Oct 1999, Christopher Petrilli wrote: > >> We are abandoning the use of DB-API interfaces for our own use simply >> because they have proven to be of little value in getting things running. >> In addition, their behavioral assumptions are sometimes quite incompatible >> with Zope requirements. Jim Fulton can better speak to this. We're now >> doing a more "thin shim" approach, and not going anywhere near the DB-API or >> SWIG. > > I guess I did "the right thing" on MySQLdb: Create a native interface > (_mysql) with a Python DB API wrapper (MySQLdb). It turned out to be very > easy to convert the old ZMySQLDA (using MySQLmodule-1.4) to use _mysql, > and MySQLmodule and _mysql are quite dissimilar. > > It might be worth pointing out (not to AMK or MAL, they know this) that > Solid's native interface is ODBC. We realize this, but SOLID has been repositioned as an embedded solution, and since we have no customers who us it, it's been pushed out to the general populace. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

1 0

Re: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
by Andy Dustman 12 Oct '99

12 Oct '99

On Tue, 12 Oct 1999, Christopher Petrilli wrote: > We are abandoning the use of DB-API interfaces for our own use simply > because they have proven to be of little value in getting things running. > In addition, their behavioral assumptions are sometimes quite incompatible > with Zope requirements. Jim Fulton can better speak to this. We're now > doing a more "thin shim" approach, and not going anywhere near the DB-API or > SWIG. I guess I did "the right thing" on MySQLdb: Create a native interface (_mysql) with a Python DB API wrapper (MySQLdb). It turned out to be very easy to convert the old ZMySQLDA (using MySQLmodule-1.4) to use _mysql, and MySQLmodule and _mysql are quite dissimilar. It might be worth pointing out (not to AMK or MAL, they know this) that Solid's native interface is ODBC. -- andy dustman | programmer/analyst | comstar.net, inc. telephone: 770.485.6025 / 706.549.7689 | icq: 32922760 | pgp: 0xc72f3f1d

1 0

ZServer hardcodes "http"
by Ng Pheng Siong 12 Oct '99

12 Oct '99

Hi, I've put together a HTTPS_Server for ZServer, based on my https_server. Let's say I run HTTPS_Server at https://127.0.0.1:8443. I can get to Zope's default main screen; however the url's returned are http, e.g., http://127.0.0.1:8443/QuickStart. That is, these are _http_ urls pointing to my _https_ server. Naturally, when I connect to such a url, the server generates a SSL23_GET_CLIENT_HELLO error, because my browser is talking http, not https. Using HTTPServer, I look at the DTML for index_html and see: <a href="/QuickStart/">QuickStart</a> material. Browse around the web UI... Didn't see anywhere to change URL1 easily. So, RTFM... Ok, found the explanation for URLn under "name lookup" in the DTML Reference. Fine. But I'm still stuck. Thus, my questions are: why is "http" hardcoded, and where do I change it? TIA. Cheers. PS. https_server comes with M2Crypto. http://www.post1.com/home/ngps PPS. I'm not subscribed to the list. Please cc your replies to me. -- Ng Pheng Siong <ngps(a)post1.com>

2 2

Re: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
by Christopher Petrilli 12 Oct '99

12 Oct '99

> Christopher Petrilli wrote: >> >> BTW, I didn't mean to imply that what you've done isn't useful, it's simply >> incompatible with the direction we're taking. This is somewhat discussed in >> my roadmap. If you'd like to maintain the interface that you're talking >> about, then that'd be excellent. > > In what way is it incompatible ? mxODBC is DB API compliant in most parts > and has lots of useful extensions such as the ODBC catalog functions. The > interface itself is thread safe and thread friendly. Of course, whether > a certain ODBC driver is depends on the driver. We are abandoning the use of DB-API interfaces for our own use simply because they have proven to be of little value in getting things running. In addition, their behavioral assumptions are sometimes quite incompatible with Zope requirements. Jim Fulton can better speak to this. We're now doing a more "thin shim" approach, and not going anywhere near the DB-API or SWIG. > FYI, mxODBC currently works with these database drivers/managers: > Adabas - Informix - MySQL - PostgreSQL - Oracle - Solid - > Sybase - Windows ODBC Manager - Unix iODBC Driver Manager - > Linux unixODBC Driver Manager - EasySoft ODBC Bridge - > OpenLink ODBC drivers - Intersolv ODBC drivers > + virtually any database supported by one of the listed ODBC > managers. The issue is more that in many cases (Oracle for example) ODBC is enormously slower than the native drivers. we've had people comment that it's something around an order of magnitude. Also, Oracle's ODBC drivers leak like the proverbial sieve. Therefore we plan to target native interfaces, rather than glued on top constructs. Only on Windows is ODBC any form of gain. Now, if X/Open CLI is the native interface (as with DB2), then this will be fine... we just plan to talk to native interfaces. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

1 0

Re: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
by M.-A. Lemburg 12 Oct '99

12 Oct '99

Christopher Petrilli wrote: > > BTW, I didn't mean to imply that what you've done isn't useful, it's simply > incompatible with the direction we're taking. This is somewhat discussed in > my roadmap. If you'd like to maintain the interface that you're talking > about, then that'd be excellent. In what way is it incompatible ? mxODBC is DB API compliant in most parts and has lots of useful extensions such as the ODBC catalog functions. The interface itself is thread safe and thread friendly. Of course, whether a certain ODBC driver is depends on the driver. > As for thread-safety, this would require more complete understanding, and > having never used mxODBC, I can't speak to its safety (which is also > dependent on the drivers). > > Note that mxODBC has an incompatible license to ours. True. mxODBC is not 100% true Open Source even though you do get to see the source code. In fact the license is going to be changed to a classical "pay for commercial, free for non-commercial use" one in one of the next versions to help finance further development (I'm planning to take the PythonWare approach here: cheap but not free). The main focus will then be to make mxODBC faster, more flexible and to provide some useful add-ons. FYI, mxODBC currently works with these database drivers/managers: Adabas - Informix - MySQL - PostgreSQL - Oracle - Solid - Sybase - Windows ODBC Manager - Unix iODBC Driver Manager - Linux unixODBC Driver Manager - EasySoft ODBC Bridge - OpenLink ODBC drivers - Intersolv ODBC drivers + virtually any database supported by one of the listed ODBC managers. IBM DB2 is on the wish list. It should work just fine once I get the linkage problems settled. -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 80 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0

RE: [Zope] Turn static HTML dynamic?
by Jay, Dylan 12 Oct '99

12 Oct '99

> -----Original Message----- > From: User Webteam [mailto:webteam@uni-bielefeld.de] > Sent: Monday, October 11, 1999 22:18 > To: zope(a)zope.org > Subject: [Zope] Turn static HTML dynamic? > > > Hi! > > We´re thinking about using Zope for our University website. > Now we face > following problem: > We need a simple solution for people who don´t want to care about DTML > to publish their documents using Composer or similar WYSIWYG tools. > These documents should be rendered with some standard HTML-code > (navigation and the like). Is there any possibility to do this without > having to teach everyone <dtml-var> etc.? We tested various things > (access rules) but in the best case we end up with nested <html> tags. > Unfortunately, we have no python experts here and we´re not learning > fast enough to present a solution within time. > > Some background info: we have to ensure that virtually erveryone here > has a simple way to put information on the net. Most of these people > have little or no HTML knowledge but use Composer, HotMetal > or even word > to create their documents. So it seems unacceptable to our bosses to > bother anyone with manipulating sources. We would really like to use > Zope because of its great management features, user management and > expandibility (and its price ;-), so any hints would be highly > appreciated. Heres my idea for this. Have a seperate ftp server running that uses different GET and PUT methods. These methods will work differently from just presenting the straight DTML. The GET method will do something like a rendering with the DTML encoded into comment tags. So <dtml-var standard_html_header> <ul> <dtml-in aList> <li><dtml-var sequence-item></li> </dtml-in> </ul> <dtml-var standard_html_footer> Would be rendered like  <html> <title>A big Title</title> <body>  <ul>  <li>Item1</li>  <li>Item2</li>   </body> </html>  Not exactly clean but it would mean a WYSIWYG editor could edit the whole page and as long as the comments were preserved then the everything would be fine. The PUT method would decode the above and turn it back into the orginal DTML. Changes inside iterations might have to be merged somewhat. Changes to server side includes could be propergated back to the included object as long as the user has permission to change it. Changes to variables like sequence-item can just be ignored. Changes to objects with which the user has no permission can similarly be ignored. Why go to all this trouble? a) It lets wysiwyg people make changes to DTML code hopefully without destroying it. b) It lets DTML people do a bit a visual design once in awhile. c) It lets beginers write content for a site that needs to have the standard footer and header on each page and still see what it looks like. d) It will allow Zope to do something no other server side scripting can do, successfully combine scripting and wysiwyg editing. e) It allows the use existing editors such as Homesite rather trying again with javascript or java or whatever. How can this be implemented? Having a quick look round the code, not easily. I think the recursive way DTML is parsed and rendered makes it hard to put extra steps between recursions. Does everyone think this a) Won't work very well b) Isn't worth it c) great idea but impossible to impliment. d) fantastic idea, I'll have it done tonight ....?

1 0

Re: [Zope-dev] ZServer hardcodes "http"
by Anthony Baxter 11 Oct '99

11 Oct '99

Hi there, Make sure your HTTPS_Server passes the environment variable 'HTTPS=on' to Zope, then it will 'do the right thing'. Anthony >>> Ng Pheng Siong wrote > Hi, > > I've put together a HTTPS_Server for ZServer, based on my https_server. > > Let's say I run HTTPS_Server at https://127.0.0.1:8443. I can get to > Zope's default main screen; however the url's returned are http, > e.g., http://127.0.0.1:8443/QuickStart. That is, these are _http_ > urls pointing to my _https_ server. > > Naturally, when I connect to such a url, the server generates a > SSL23_GET_CLIENT_HELLO error, because my browser is talking http, not > https. > > > Using HTTPServer, I look at the DTML for index_html and see: > > <a href="/QuickStart/">QuickStart</a> material. > > Browse around the web UI... Didn't see anywhere to change URL1 easily. > > > So, RTFM... Ok, found the explanation for URLn under "name lookup" in > the DTML Reference. > > Fine. But I'm still stuck. > > Thus, my questions are: why is "http" hardcoded, and where do I change > it? > > TIA. Cheers. > > > PS. https_server comes with M2Crypto. http://www.post1.com/home/ngps > > PPS. I'm not subscribed to the list. Please cc your replies to me. > > -- > Ng Pheng Siong <ngps(a)post1.com> > > > _______________________________________________ > Zope-Dev maillist - Zope-Dev(a)zope.org > http://www.zope.org/mailman/listinfo/zope-dev > > (Related lists - please, no cross posts or HTML encoding! > > To receive general Zope announcements, see: > http://www.zope.org/mailman/listinfo/zope-announce > > For non-developer, user-level issues, > zope(a)zope.org, http://www.zope.org/mailman/listinfo/zope ) -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Re: [DB-SIG] Re: [Zope-dev] Prototype Zope mxODBC DA
by M.-A. Lemburg 11 Oct '99

11 Oct '99

Christopher Petrilli wrote: > > > Question for Christopher Petrilli: because the patches from the Oracle > > DA are so small, does merging the mxODBC and Oracle DAs into one code > > base seem feasible? What mxODBC DA are you referring to here ? Is there something I've missed ? > No, mostly because both are on the cusp of going somewhere else. We will > most likely be undertaking a ground-up rewrite of the ODBC driver based > purely on the X/Open CLI spec (which is part of SLQ99), which will also be > used to talk to DB2. This will not use a DB-API compatible interface for > various reasons. > > Eventually the DCOracle adapter will undergo a similar transition. We need > things that the DB-API doesn't provide, nor perhaps should it. We have > already had great success with a Sybase adapter done this way (eventually to > be released). Note that mxODBC does already link against the Linux ODBC driver of IBM's Universal Database (DB2). It's just that the dynamic load doesn't work due to some obscure compiler or linker bug, at least not on my machine using the latest beta code from IBM (haven't yet received the final product CD). Chris, could you elaborate a bit on what features you need that are not included in the DB API Spec ? -- Marc-Andre Lemburg ______________________________________________________________________ Y2000: 81 days left Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

1 0

Re: [Zope-dev] Prototype Zope mxODBC DA
by Christopher Petrilli 11 Oct '99

11 Oct '99

BTW, I didn't mean to imply that what you've done isn't useful, it's simply incompatible with the direction we're taking. This is somewhat discussed in my roadmap. If you'd like to maintain the interface that you're talking about, then that'd be excellent. As for thread-safety, this would require more complete understanding, and having never used mxODBC, I can't speak to its safety (which is also dependent on the drivers). Note that mxODBC has an incompatible license to ours. Chris -- | Christopher Petrilli Python Powered Digital Creations, Inc. | petrilli(a)digicool.com http://www.digicool.com

1 0