Hi. There is interest at work in doing some fairly simple inventory
control using a database. We've already got Postgres up and running
(for obvious reasons) and I was wondering if anyone had suggestions
for a good approach to app development for brower-based user
interfaces.

There are other applications which would be of interest, so something
with some growth potential would be helpful.

We have a bit of expertise in Java servlets, etc, so that is one
option via the jdbc interface.

Are there any options which are particularly "approachable" which
would allow newbies to get something working if they have some
existing code to look at?

TIA

                     - Thomas

-- 
Thomas Lockhart				lockhart@alumni.caltech.edu
South Pasadena, California

Thu, 29 Jul 1999 16:20:09 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
web-based front end development
Thomas - 
I'd suggest you have a look at the Zope system (www.zope.org). It's a
through-the-web development environment, designed for ease of partitioning 
the development and maintanence of web-based apps. 

One could think of it as a cross of Cold Fusion and PHP on steroids. It's
actively being developed in an Open Source way, with Digitial Creations,
Inc. as lead developers (only fair, it's their code they donated to
us all).

The partitioning allows you to write the SQL parts (as ZSQL methods),
and have someone else use them in a 'blackbox' fashion to design the
app. using DTML, the Zope HTML scripting language. It's relatively easy
to extend this to having 'content' people do just that, content. Not an
HTML tag in sight (for them).

At first glance, it may look a little heavyweight for 'simple' app., but
we all know that those simple apps grow, and you never get a chance to
rewrite from scratch untill you have too.

Now the bad news. The current beta has lots of nice new features,
but in the process of adding some of them (better concurrency, and
a new implementation of their transaction system), all the database
adaptors broke. They still work fine for the current stable, 1.10.2,
however. It's just that there are major features (ZClasses, XML support)
in the beta that could affect fundamental design decisions for any app
you'd start now.

I think it'd be a major win for both systems to have such a core member
of the PostgreSQL development using Zope. Give me 'till Monday and I'll see
if I can't get the ZPyGreSQLDA (ow, painful name!) working acceptably with
Zope 2.0. (I need it anyway, even if you don't go with Zope)

Ross
-- 
Ross J. Reedstrom, Ph.D., <reedstrm@rice.edu> 
NSBRI Research Scientist/Programmer
Computer and Information Technology Institute
Rice University, 6100 S. Main St.,  Houston, TX 77005

Thu, 29 Jul 1999 11:50:44 -0500
"Ross J. Reedstrom" <reedstrm@wallace.ece.rice.edu>
Re: [HACKERS] web-based front end development
Thomas Lockhart wrote:
> (for obvious reasons) and I was wondering if anyone had suggestions
> for a good approach to app development for brower-based user
> interfaces.
 
> There are other applications which would be of interest, so something
> with some growth potential would be helpful.

> Are there any options which are particularly "approachable" which
> would allow newbies to get something working if they have some
> existing code to look at?

My recommendation is AOLserver 3.  If you know any tcl, you can deal
with AOLserver's tcl.  AOLserver is a complete, lightweight,
multithreaded, industrial-strength, open source powerhouse of a web
server, available from www.aolserver.com.  There are many examples
available.  AOL runs their www.aol.com and www.digitalcity.com sites on
AOLserver -- this thing is a performance beast!  Postgres is well
supported under the older 2.3 series and the newer 3.0 series.  2.3 is
not open source, though. 

In fact, AOLserver's support of Postgres is why I got started with
PostgreSQL in the first place -- the seamless db connectivity was just
too tempting. Database connections are pooled and throttled, so that
only as many backends as your server can support can be loaded at any
time.  Connection threads share pooled connections -- a new backend is
not spawned for each an every page request -- AOLserver was the first
web server with this capability, BTW.  AOLserver will cooexist with
other web servers on the same box -- you can have it listen to any port
you desire, on any interface.

AOLserver allows embedded tcl inside HTML pages -- and the tcl has
complete run of the database.  For administration, a telnet control port
is available that allows execution of operating system commands, tcl
commands, and direct entry of SQL -- like having its own psql built-in.  

Version 3 is currently at beta 2, but development is heavy.  

And, AOL is using this for their highest traffic sites.

The interactive development community site is at aolserver.lcs.mit.edu,
and is run by the guys behind ArsDigita (the best known of whom is
Philip Greenspun, Mr. Database-backed-website himself.).  Their
ArsDigita Community System (ACS) is written for the 2.3 server, but is
chock full of example code that runs backed by Oracle, although an
effort is underway to port over to PostgreSQL.

The learning curve is surprising shallow, with any experienced
programmer taking maybe a day or so to get up to speed on AOLserver's
dialect of tk-less tcl.  I have run this system for over two years, and
it works very well.

For more information on Greenspun's philosophy and on AOLserver itself,
check out the book "Philip and Alex's Guide to Web Publishing",
available at amazon.com or for free at photo.net/wtr/thebook -- this
book really is a must-read.

HTH.

Lamar Owen
WGCR Internet Radio

Thu, 29 Jul 1999 12:53:25 -0400
Lamar Owen <lamar.owen@wgcr.org>
Re: [HACKERS] web-based front end development
On Thu, 29 Jul 1999, Thomas Lockhart wrote:

> Hi. There is interest at work in doing some fairly simple inventory
> control using a database. We've already got Postgres up and running
> (for obvious reasons) and I was wondering if anyone had suggestions
> for a good approach to app development for brower-based user
> interfaces.
> 
> There are other applications which would be of interest, so something
> with some growth potential would be helpful.
> 
> We have a bit of expertise in Java servlets, etc, so that is one
> option via the jdbc interface.
> 
> Are there any options which are particularly "approachable" which
> would allow newbies to get something working if they have some
> existing code to look at?

Dmitry was working on something like that; I couldn't wait and wrote
one in C.  His is in perl. Handles inventory, invoice printing (one at a
time on demand), special prices and a few other minor things.  Probably
could use to be cleaned up some tho.  This one runs with Apache, but one
day I'll probably rewrite it to use my micro-webserver so a full web
server wouldn't be a requirement.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null
       # include <std/disclaimers.h>                   TEAM-OS2
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Thu, 29 Jul 1999 12:55:21 -0400 (EDT)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] web-based front end development
> Hi. There is interest at work in doing some fairly simple inventory
> control using a database. We've already got Postgres up and running
> (for obvious reasons) and I was wondering if anyone had suggestions
> for a good approach to app development for brower-based user
> interfaces.
> 
> There are other applications which would be of interest, so something
> with some growth potential would be helpful.
> 
> We have a bit of expertise in Java servlets, etc, so that is one
> option via the jdbc interface.
> 
> Are there any options which are particularly "approachable" which
> would allow newbies to get something working if they have some
> existing code to look at?

PHP is a must see.  See FAQ.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thu, 29 Jul 1999 13:02:34 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] web-based front end development
At 04:20 PM 7/29/99 +0000, Thomas Lockhart wrote:

>Hi. There is interest at work in doing some fairly simple inventory
>control using a database. We've already got Postgres up and running
>(for obvious reasons) and I was wondering if anyone had suggestions
>for a good approach to app development for brower-based user
>interfaces.

I'm fond of AOLserver and its TCL API, which has built-in pooled
db connectivity, maintaining persistent db connections with
no forking overhead.  The webserver itself schedules TCL threads,
there's no CGI forking overhead as with older style Perl, etc
interfaces (of course, Apache + modPerl etc now implements a similarly
efficient interface).  AOLserver's open source, GNU-licensed, and
also supports CGI and a C API.  It works with many dbs, including
Postgres.

The integrated TCL API has been extended with literally dozens
of website-useful extensions to connect to the db, do selects,
do dml, get table info, send e-mail ("ns_sendmail to from message 
extraheaders" - this gives a flavor of the ease in which one
gets things done in this environment), schedule TCL scripts
(I use this feature to do nightly pg_dumps), load pages from
other URLs, upload files from client browsers, etc etc etc.
If you're at all familiar with TCL you could have a few modest
pages up and running within hours of downloading the server
and the utilities package mentioned below.

An example of a website built using this combination plus
postgres 6.5.1 can be found at http://donb.photo.net/tweeterdom.

ArsDigita has a ton of code available to implement bboards,
e-commerce, bug (ticket) tracking, chat, and a bunch of other
stuff which sits on top of Oracle.   I've found this stuff easy
to migrate to Postgres - the TCL scripts don't need changing
other than the actual SQL, which is mostly vanilla.  The lack
of an outer join gets in the way of porting some of this code,
thus those who've discussed porting the complete ArsDigita system
are eagerly awaiting Postgres 6.6.

Other than that, the fact that Postgres implements sequences
in a way very much like Oracle with a just slightly different
syntax makes porting the SQL fairly easy.  My particular
application doesn't include any of the specific modules
implemented by ArsDigita, other than that used to register
and log in visitors.  But, I've poached a bunch of code from
the modules to avoid wheel-reinventing in a bunch of my own
stuff.

ArsDigita also has prototyping scripts available that quickly
builds form-based entry and edit pages from tables.  This is
new, again is Oracle-based, but should be easy to move to
postgres.

They also supply a rich set of utilities which greatly
simplify using the db and forms, whether or not you use
their other tools.

All of this stuff's available from ArsDigita under the GNU
license as well, at arsdigita.com.

While not well-known, AOLserver, the ArsDigita stuff, and
Oracle lie underneath some very busy sites.  Postgres 6.5.1
isn't quite robust enough to measure up to Oracle yet for
a truly busy site, but is so much better in the web environment
than 6.4 that I think it's really reasonable for modest sites,
up to a few ten thousands of hits a day at the very least.

I've tested the AOLserver+TCL+Postgres on a P200 classic
with Linux, 64 MB (running postgres -B 2000), and two IDE
disks (indices on one, datafiles on the other).  On another
LAN-connected machine I fired up a bunch of browsers and
used them to run test scripts which simulated ten users 
each doing four inserts a second, and two users doing
"selects" in tight TCL loops (did this in part to test
the changes which removed the unneeded logging after read-only
selects).  The machine was perfectly happy performing these
tasks, not falling behind a bit.  The four inserts were bundled
into a single transaction, so that's ten transactions a second
consisting of forty inserts.  A lot of hits for a tiny machine,
really.  Says a lot for Postgres, Linux, the web server and its
TCL API, not to mention the speed and capacity of modern 
microcomputers!

If you're doing simple web applications, a straight interpreter,
be it TCL, Perl or whatever, has some advantages over a compiled
language.  You make your changes, and poof! they're there, no
recompiling, relinking, etc.  

Of course, I wouldn't use TCL for a large program requiring 
hundreds of thousands of lines of code...but it does have a
reasonably clean syntax and the basic loop, select, if-then-else
structures and the ability to declare procedures.

The very nature of HTML imposes a structure on web programs
which is oriented around web pages, i.e. if you take input
via a form, that's a page.  You process it and stuff into or
inquire from a database in the page that's the "action"
target of the form.  You get to form pages via hyperlinks,
and normally they live on separate pages because that's the
natural way to present things to the user.

So the structure's typically not one imposed by the programmer's
decomposition of the problem in some abstract sense, but rather
your decomposition of the page flow through the client browser,
i.e. the design of the interface as you wish the user to see
it.  That page flow design leads you around by the nose as you
develop the code underlying them (either html with embedded
TCL (.adp pages), or as I prefer scripts which write html (.tcl
pages), in AOLserver - ASP pages and ColdFusion-augmented 
html are much like AOLserver .adp pages, CGI+Perl more like
the .tcl page approach).

>From the point of view of the user, this is almost cool - the
programmer's FORCED to design the user interface and the 
page flow that takes the user through it.  The UI - primitive
as it is - steps forward front-and-center, by necessity.  One
can hope, at least, that the need to focus here leads to better
UIs, though of course HTML is so primitive that UIs are awkward
unless you get deep into client side java/javascript, which has
a lot of problems of its own.

Because of this, actual web code I've seen looks remarkably
the same regardless of the language being used.  Much of
it is dominated by the writing of html, and shoving stuff
back-and-forth between pages (by URLencoding or hidden
form variables - html concepts, not Tcl or Perl or Java
concepts).  

So I think it might be best to concentrate on looking for
combinations that can scale to high levels of activity, which
means avoiding CGI's forking interface (Apache and AOLserver
are both good at this), pooling DB connections (to avoid
forking off new db backends each time you connect), etc.

I'm using Linux+AOLserver+their Tcl API+Postgres+ArsDigita code
because the combination can service a lot of users on a cheap PC,
and it's all open-source/free software, not because I love Tcl
(I don't).  The scripts underlying the sample site I gave above are
such relatively short and simple programs, though, that I don't mind
much what language I'm writing them in, language choice in this
case was a secondary consideration.

(given I'm a professional compiler writer, it still seems weird
to hear these words come from my mouth).




...

>Are there any options which are particularly "approachable" which
>would allow newbies to get something working if they have some
>existing code to look at?

If you're interested in the AOLserver approach, visit the ArsDigita
web site and poke around.  You can download source code to all their
stuff to see what stuff look like.



- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, and other goodies at
  http://donb.photo.net

Thu, 29 Jul 1999 10:55:40 -0700
Don Baccus <dhogaza@pacifier.com>
Re: [HACKERS] web-based front end development
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> Hi. There is interest at work in doing some fairly simple inventory
> control using a database. We've already got Postgres up and running
> (for obvious reasons) and I was wondering if anyone had suggestions
> for a good approach to app development for brower-based user
> interfaces.
> 
> There are other applications which would be of interest, so something
> with some growth potential would be helpful.
> 
> We have a bit of expertise in Java servlets, etc, so that is one
> option via the jdbc interface.
> 
> Are there any options which are particularly "approachable" which
> would allow newbies to get something working if they have some
> existing code to look at?

Since you explictly mention Java, you could look at the Java Apache
project, which apparently implements the java servlet
interface. (http://java.apache.org)

If you like Perl, Apache + mod_perl + HTML::Mason have done right by
me for a number of projects. I think it's incredibly approachable (and
powerful), but I've got four years of solid perl experience and like
the language a lot---YMMV.  (http://perl.apache.org/,
http://www.masonhq.com/)

If you like TCL, AOLServer definitely deserves a look, as others have
said. It's also a nice, low overhead server to administer.
(http://www.aolserver.com/, http://www.arsdigita.com/)

PHP has a lot of activity, and is supposed to be really fast if you
compile it right into your apache server, although it's often YANAL
for people to have to learn. (http://www.php.net)

Roxen Challenger, with its Pike language and many other nifty features
is also worth a glance, though it's also got the YANAL stigma.
There's both a commercial version and a GPL'd
version. (http://www.roxen.com/)

With the exception of the Java stuff, I am personally aquainted with
significant projects that have been implemented in each of these
environments---all of them have the ability to support large projects,
though I don't know how well they support programming in the large.

I suspect approachability may initially hinge on language familiarity.
If you have to learn a whole new language, you're probably going to
have a steeper learning curve.

Mike.

29 Jul 1999 14:37:54 -0400
Michael Alan Dorman <mdorman-pgsql.hackers@debian.org>
Re: [HACKERS] web-based front end development

On 29-Jul-99 Thomas Lockhart wrote:
> Hi. There is interest at work in doing some fairly simple inventory
> control using a database. We've already got Postgres up and running
> (for obvious reasons) and I was wondering if anyone had suggestions
> for a good approach to app development for brower-based user
> interfaces.

You begin the star war ;-))

I use three different interface for different tasks 

Firstly, I use php3 to make web based interface 
http://www.piter-press.ru is an example (not the best, but the only public
available)
PHP3 code looks like

 $qu = pg_exec($conn, "select * from users where (uid = '$uid');" );
        $nm = pg_numrows($qu);
        if ($nm > 0)
           {
             $data = pg_fetch_object ($qu, $i);
             $xpin = crypt($pin, $data->pin);
             if ($xpin == $data->pin)
                 { BlueEcho("PIN of user '$uid' is valid");
                 }
               else
                {  RedEcho("Sorry, you enter incorrect PIN for user '$uid'");
                }
           }

       pg_close($conn);

and seems to be very convenient for sambody familiar with perl or C

Secondly, I use Perl every time as I need write anything for five minits 
just because I use Perl about five years.

Perl code looks like (I skip any error check, usually doing inside runSQL)

  my $connect_args = 'dbname=voip host=nymph.wplus.net user=dms';
  my $conn = Pg::connectdb($connect_args);
  my $query = "select uid from users where(opstatus=1 and manstatus=1 and units
< $insure)

 $result = $conn->exec("BEGIN");
 $result = $conn->exec("DECLARE killer001 CURSOR FOR $query;");

  open(EMP,"|$empress");

  while( ($result = Voip::runSQL($conn, "FETCH FORWARD 1 IN
killer001;"))  )
  { while (@row = $result->fetchrow)
     {
       runSQL($conn, "begin");
       runSQL($conn, "update users set opstatus=2 where(uid = '$row[0]');");
        print EMP "update its_user set acctstatus=1 where(userid =
'$row[0]');\n";
       runSQL($conn, "commit");
       print "User $row[0] disabled\n";
     }
   }

  runSQL($conn,"CLOSE killer001;");
  runSQL($conn, "END");
  $conn->reset();

Third, I use C++ for really hard tasks (By historical reasons, I use my own
library, not libpq++) 
C++ code looks like 

  pgs = new PgSQL(listdb);
  pgs->trace();

 sprintf( (char *)qbuf,"select id, email from %s where( msgid < %d );", 
                                       (char *) list, msgid);
 pgs->openCursor( (char *)qbuf);

       while( pgs->fetchNext() )
         {
             sprintf(update,"update %s set msgid=%d where( id = %s);", 
                                                      (char *)listn, msgid
             send_proc(qbuf, (char *) (*pgs)["email"], fm, (char *)
                                                              update );
         } // while 

     pgs->closeCursor();
     delete pgs;

I also try to use Java but I find no appropriate task for it.
Main disadvantage to Java - is lots of incompatible browser versions,
for example Lucent made java interface works only on 2 MS Win based 
workstations and 0 of UNIX based from about 80 comps. All other have
fonts, security manager or other problems ;-)) 
(but it's my opinion - any of Java gurus may be completely disagree with me
;-))  )


IMHO, PHP3 is the best choice for Web it self, but bakground programs 
should be written in C/C++

So, make your choice and good luck  ;-))


> 
> There are other applications which would be of interest, so something
> with some growth potential would be helpful.
> 
> We have a bit of expertise in Java servlets, etc, so that is one
> option via the jdbc interface.
> 
> Are there any options which are particularly "approachable" which
> would allow newbies to get something working if they have some
> existing code to look at?
> 
> TIA
> 
>                      - Thomas
> 
> -- 
> Thomas Lockhart                               lockhart@alumni.caltech.edu
> South Pasadena, California

---
Dmitry Samersoff, dms@wplus.net, ICQ:3161705
http://devnull.wplus.net
* There will come soft rains ...

Thu, 29 Jul 1999 23:49:59 +0400 (MSD)
Dmitry Samersoff <dms@wplus.net>
RE: [HACKERS] web-based front end development
Thus spake Dmitry Samersoff
> On 29-Jul-99 Thomas Lockhart wrote:
> > (for obvious reasons) and I was wondering if anyone had suggestions
> > for a good approach to app development for brower-based user
> > interfaces.
> 
> You begin the star war ;-))
> 
> I use three different interface for different tasks 

[PHP3, Perl and C++ discussion ellided]

Or, use Python for everything.

> Firstly, I use php3 to make web based interface 

I use Python over PHP because, like PHP, Ican embed it into the web
server but I can reuse the code in non-web applications so I don't
have to reinvent each wheel.

> http://www.piter-press.ru is an example (not the best, but the only public
> available)
> PHP3 code looks like
> 
>  $qu = pg_exec($conn, "select * from users where (uid = '$uid');" );
>         $nm = pg_numrows($qu);
>         if ($nm > 0)
>            {
>              $data = pg_fetch_object ($qu, $i);
>              $xpin = crypt($pin, $data->pin);
>              if ($xpin == $data->pin)
>                  { BlueEcho("PIN of user '$uid' is valid");
>                  }
>                else
>                 {  RedEcho("Sorry, you enter incorrect PIN for user '$uid'");
>                 }
>            }
> 
>        pg_close($conn);

for data in db.query("select * from users where uid = '%d'" % uid).dictresult():
	if crypt(pin, data.pin) == data.pin:
		print "PIN of user '%d' is valid" % uid
	else:
		print "Sorry, you enter incorrect PIN for user '%d'" % uid

I assume that BlueEcho and RedEcho are simply functions that wrap the
strings in font color tags.  Such functions can easily be added to Python.
See http://www.druid.net/rides/ for a real example.

> Secondly, I use Perl every time as I need write anything for five minits 
> just because I use Perl about five years.

I use Python over Perl because I find it to be a cleaner and more logical
language.  This is a personal preference thing, of course.

> Third, I use C++ for really hard tasks (By historical reasons, I use my own
> library, not libpq++) 

I hardly do anything in C (never cared much for C++ except for a few
specific features) any more as Python gives me the ability to do anything
I could do in C and, if needed, I can always write low level code in C
and link it in.

Check out http://www.python.org/ for more information.  For a PostgreSQL
interface for Python see http://www.druid.net/pygresql/ or look in the
PostgreSQL source tree.

> IMHO, PHP3 is the best choice for Web it self, but bakground programs 
> should be written in C/C++

As I said, one language for all makes code reuse easier. I find that my
projects generally require web interfaces, CLI interfaces as well as
scheduled background tasks and I can write modules that get imported into
all of them saving me much development time.

> So, make your choice and good luck  ;-))

Can't argue with that.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

Fri, 30 Jul 1999 08:02:45 -0400 (EDT)
"D'Arcy" "J.M." Cain <darcy@druid.net>
Re: [HACKERS] web-based front end development
At 11:49 PM 7/29/99 +0400, Dmitry Samersoff wrote:
...

> $qu = pg_exec($conn, "select * from users where (uid = '$uid');" );
>        $nm = pg_numrows($qu);
>        if ($nm > 0)
>           {
>             $data = pg_fetch_object ($qu, $i);
>             $xpin = crypt($pin, $data->pin);
>             if ($xpin == $data->pin)
>                 { BlueEcho("PIN of user '$uid' is valid");
>                 }
>               else
>                {  RedEcho("Sorry, you enter incorrect PIN for user '$uid'");
>                }
>           }
>
>       pg_close($conn);

Tcl code in AOLserver looks roughly like this (using the utilities
package from ArsDigita as well as AOLserver Tcl extensions):

# Note that this gets a persistent handle, i.e. the overhead is
# simply that of assigning a handle pointer from a pool

set db [ns_db gethandle]
set selection [ns_db select $db "select * from users where (uid='$uid')"
while {[ns_db getrow $db $selection]} {
    set_variables_after_query
    if {$pin == ...

}

ns_db releasehandle $db

>and seems to be very convenient for sambody familiar with perl or C
>
>Secondly, I use Perl every time as I need write anything for five minits 
>just because I use Perl about five years.
>
>Perl code looks like (I skip any error check, usually doing inside runSQL)

>  my $connect_args = 'dbname=voip host=nymph.wplus.net user=dms';
>  my $conn = Pg::connectdb($connect_args);

This is bad for websites - building a new db connection is expensive.

This is why AOLserver provides pooled connections.

This is why Apache/modperl types use packages that pool persistent
connections if they plan to build a busy site.

>  my $query = "select uid from users where(opstatus=1 and manstatus=1 and
units
>< $insure)
>
> $result = $conn->exec("BEGIN");
> $result = $conn->exec("DECLARE killer001 CURSOR FOR $query;");

As you can see, when it gets down to it, all of these solutions have
more in common than in differences.

The key to look at, IMO, is the efficiency of the webserver and its
database connectivity.

...




- Don Baccus, Portland OR <dhogaza@pacifier.com>
  Nature photos, on-line guides, and other goodies at
  http://donb.photo.net

Fri, 30 Jul 1999 11:13:39 -0700
Don Baccus <dhogaza@pacifier.com>
RE: [HACKERS] web-based front end development