>However, we want to avoid
>writing code to particular vendor-supplied APIs where possible. And that
>includes AOLServer database drivers, and the ns_set API. This probably
>sounds utopian, but what we'd really like, if possible, is to make all major
>hardware and software components into commodity items. If we don't like the
>OS, we jerk it out and plug a different one in. Same goes for the web
>server software, the database back-end and its drivers, and even the
>scripting language. You can't just port all your code to another scripting
>language overnight, but you can leave yourself options to switch to another,
>and that's what we want. The rest of those pieces can be abstracted or
>emulated if the .ASP's or .ADPs are built correctly to begin with. A
>powerful and portable language like TCL supports that degree of abstraction.
Even with AOLserver and the ns_db API, I would think you'll still be
writing the same SQL you would be writing from perl, C, or what have you.
Gosh, I just don't know how you're going to get around writing to the ns_db
api and still use AOLserver. You may find that a tcl lib will do what you
want, if so, please let us know what you're hosting that tcl lib with, or
what performance you see. I guess I wouls say that ns_db is essentially
jdbc. You write SQL and you need to wrap it in something. That something
is ns_db. But the SQL will be the same.
>We're sick of being locked into a platform (in our case
>IIS/ASP/VBScript/ADO/MSSQL/WinNT) and don't want to make that mistake again.
Yeah, I hear ya, and that frankly is a major reason that folks choose
Apache and/or Java over AOLserver. That is, they want to pick the largest,
openest platform they can find. Most of us here choose AOLserver over
Apache for a different reason: productivity. If the AOLserver solution
fits, it is very easy to get your system up and running.
>If Linux is a possibility in the future, you may wish to consider using it
> >now or benchmarking it. Also, another choice you may wish to look into now
>
>Linux is a "go" as soon as I can assemble the rest of the pieces to make it
>a viable platform for application/web serving. And hooking to SQL Server
>for now. It looks like AOLserver or Apache+mod_dtcl will be involved. I
>just try things on NT first because they're usually easier to install, and
>to verify that each piece will also work on NT. Our firewall is on Linux (I
>built it).
I can't tell you about mod_dtcl, but all you'll need for NT is AOLserver
and nsodbc (or my odbc stuff). All you'll need for linux is AOLserver,
nsodbc, or my odbc stuff, easysoft's bridge or dossy's nsfreetds. But that
does imply you use the ns_db API.
> >if Linux is a future migration path is using Postgres instead of SQL
> >Server. Postgres runs on both Linux and Windows, and that will also give
>
>Postgres is a big possibility later on. I still have to give it the
>shake-down, and find some developer tools for it similar to MS SQL Server
>Enterprise Manager. We like that tool, at least for the moment. Any URLs
>for those tools would help.
I haven't used them, but postgres comes with some tcl/tk based tools to
help you do that. I can't imagine any of these tools are as easy or
powerful as Enterprise Manager though. Enterprise Manager really is slick.
Jerry
=====================================================
Jerry Asher [EMAIL PROTECTED]
1678 Shattuck Avenue Suite 161 Tel: (510) 549-2980
Berkeley, CA 94709 Fax: (877) 311-8688
