[PYTHON DB-SIG] Strawman API
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
network
or:
client Python ODBC classes <---> ODBC Server <---> DB Server
(independent of server)
I would love to see some comments.
Peter
=================
DB-SIG - SIG on Tabular Databases in Python
send messages to: db-sig@python.org
administrivia to: db-sig-request@python.org
=================