Status Report of DB2 stuff
Schedule
--------
I am still working on the "connection manager" program. I seriously
underestimated the difficulty of this task - I have been spending 6-8 hours
a day on this and am still not finished. I originally estimated this task
at about 1 week in duration and have been working on it for about 4 weeks.
Why bother?
-----------
The goal of the "connection manager" for the WD site is to speed up the
serving of HTML pages that are stored in the database. Using "normal"
database connections each page that is served requires a connection, and
each connection (on a 500mhz pentium III machine) takes 3-5 seconds. With
the connection manager that connect time can (potentially) be decreased to
probably less than 1 second.
Do we need it for the first WD site release?
--------------------------------------------
No. We could get by without it.
So why do it now?
------------------
I was trying to kill 4 birds with one stone
1) WD connection speed - we have talked about this previously
2) Provide ODBC access using non-licensed Intersolv ODBC drivers. Intersolv
no longer sells ODBC database drivers to individuals - although they will
sell them to resellers/developers who are willing to invest $10k or more.
So the only generally available Intersolv ODBC database drivers are those
that are bundled with applications like Smart Suite and those that are
available in demonstration packages. When those drivers are used by a
PM program (other than the one bundled with the drivers) the Intersolv
driver throws repeatedly throws up a annoyware dialog box that make
pratical usage impossible.
3) Provide access for OS/2 applications to data on other machines, e.g.
WinOS2 and Windows NT/2000/etc.
4) Fit in with my existing schedule for OS2eZine ODBC articles
All four issues are solved by the same technology - connecting to a
database/ODBC data source with one program and transferring the data
through named pipes to the user program. This solves the problems by:
#1 WD: by maintaining one/many open database connections and pipes - the
CGI
program just opens the other end of the pipe and has an instant connection.
#2 Intersolv license: The PM application starts a detached/non-PM program
that makes the actual database connection thereby bypassing the Intersolv
license mechanism, and communicates with the detached program to get the
data.
#3 Access to data on other machines: Since pipes are the only interprocess
communication method available between OS/2 and DOS (hence WinOS2), and
since pipes can also communication across a network and are supported on
Windows WIN32 machines, an OS/2 application can start a process on WinOS2
or Win32 that connects to the database and then access the data via named
pipes to that process. Meaning that an OS/2 application could utilize, for
example, data in a MS Access database or data using an ODBC database driver
that was released for Windows 3.1 but never for OS/2.
#4 OS2eZine articles: I was right at the point in the ODBC series of
covering writing programs using ODBC. My objective in starting the ODBC
series in OS2eZine was to promote the development of applications that used
ODBC to access data. Of course that is not very realistic if there are no
available drivers - or if the only drivers that are available will not work
with PM programs other than Lotus Smart Suite. So I needed to explain how
to get around the Intersolv issue. Plus my plan was to next month cover
some data access visual parts for use in VAC++ Visual Builder; then
to SOM-ize the data access classes (the front end) so that Object Rexx can
use them to get ODBC data access to Rexx programs.
Given the timing of the article series, and my grossly short-sighted
estimate of how long it would take to write the data transport part - the
part the sends the data down a pipe and re-assembles it at the other end -
I thought that goals 2-4 would match nicely with the WD needs.
What are the alternatives?
--------------------------
1) Stop work on the "connection manager" thingy and build the first
iteration of the WD site using the existing stuff.
This would certainly get the WD site up and running quicker. It would have
an impact on my other activites, mainly the OS2eZine ODBC article series. I
am cancelling the March ODBC article bacause I will not have enough time to
write it - and besides without the ability to use ODBC database drivers
that most people can get ahold of in PM programs there isn't much point in
discussing how to build PM programs that use ODBC. So I would probably stop
the series - or delay it by another month or 2, which is effectively the
same thing.
2) Keep slugging it out.
While this does not provide much additional benefit to WD directly (at
least at first), I hope that it provides more benefit to the OS/2 community
since it opens up avenues for data access that don't currently exist. Or
rather don't exist very easily. Given my past estimating record for this
task I am afraid to say how much longer this will take. I have coverted 6
of the 7 C++ classes involved to work with data throught the pipe. (I will
say that my wife is KILLING me for spending so much time on this - she
has a kitchen that needs remodeling.)