Dr Peter J. Braam Dr Peter J. Braam" <braam@stlawrence.maths.ox.ac.uk
Sat, 13 Jan 1996 15:39:40 +0000 (GMT)

I am pretty new to the list, excuse me if I am missing the point.  I would
like to make some further suggestions regarding the API. 

What is suggested to be implemented here is a set of classes, which we 
presumably would build _using_ the API libraries of the DB Server. This is 
certainly a necessary and useful set of classes to have.  The classes 
would be directly useful to access the DB on any platform where we could 
compile in the DB server API libaries. 

In practice, often, the clients will be running on Windows machines, not 
just on the machines where the server runs. Using Python, perhaps in 
combination with the MFC, could be a killer development environment on 
Windows. Now how can we get in touch with the DB server?

To get in touch with the DB server from another machine could be done in 
numerous ways:
1) open sockets directly and deal with the network library of the server 
   disadvantage: very dependent on the DB server
   advantage: fast, low overhead
2) purchase ODBC server and client libraries and use these
   disadvantage: you have to _purchase_ ODBC software which is 
                 _dependent_ on the server
   advantage: you could build server independent Python classes to access 
              the database
3) extend the suggested DB api with Python classes that can be accessed 
   over the net.  In other words, concentrate right away on building a 
   Python API as well as a Python net DB API.
   disadvantage: more work
   advantage: costs nothing. We could construct very nice classes (much 
   nicer than the ODBC classes) either by using the basic suggested 
   classes and implementing in terms of these, or using nice classes from 
   the DB server. We are not adding much platform dependent code.
4) extend the suggested DB API with http-useful features. I am thinking 
   about some python classes that:
    a) would be invoked through a cgi script
    b) would spit out HTML forms enhanced with Python or Java control 
       code to make the forms useful for DB access through Grail or a 
       Java aware netbrowser. 

With regards to 3) I am particularly concerned about things like cursors.
It is a long way to go from an SQL cursor to a nicely scrollable list of
rows in a windows environment.  Postgres introduced so called "portals"
which make this a lot easier, and we could perhaps consider implementing a
portal object (or using it through Postgres directly) and making that
available over the net. 

In relation to 4) it should be possible to build simple DB clients
completely in terms of HTML and some Python/Java classes shipped down with
them. In effect, we are using a universal windowing tool, which we ship
enhanced standard widgets.  I don't think one could easily reach the
quality of a first rate custom designed interface, but it could be done in
a fraction of the time. (Hopefully some CS students here are going to 
hack something out along these lines. Of course, Oracle is planning 
something similar.)

So the picture I would love to see is:

client Python DB classes  <--->    Python Net-DB API  <---> DB Server
or CGI script            network
(indep. of DBarchitecture) 
instead of: 

client Python DB classes  <--->  DB Server 


client Python ODBC classes <---> ODBC Server  <---> DB Server
(independent of server) 

I would love to see some comments.


DB-SIG  - SIG on Tabular Databases in Python

send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org