- From: George Feinberg <gmf@odi.com>
- Date: Wed, 18 Sep 1996 12:07:25 -0400 (EDT)
- To: tsaltd@panix.com (Steve Mintz)
- Cc: www-rdb@w3.org
> Glad we are talking again. > > I'd like to see some discussion about the pros and cons of the use > of middleware products (Nomad WEBDBC, the Oracle and Sybase products, > Cold Fusion, Spyder, MS IDC, Live Wire) vs applications specific CGI and Pearl solutions. > > I've heard alot about the advantages of products that work "in process" and talk directly to NSAPI and ISAPI vs "out of process i.e.: CGI > scripts" > > My opinion is that CGI/Perl is "old school" and that the future of client/server www functionality is clearly based on in-process middleware > solutions. > > Hope this sparks some discussion. OK, I'll bite. I agree that in the future, people won't be writing CGI programs, or Perl directly. What web developers want is value-added middleware. This can be things like: 1) easy/automatic database access, 2) scripting language integration, 3) HTML extensions (probably part of above) 4) other extension "objects," such as modules to deal with state across sessions, user registration, authentication, or any other piece of function that can be easily abstracted from common web applications This puts the burden of in-process vs out-of-process (execution environment) on the suppliers of the middleware. That is, a web developer should be able to choose the middleware they like, develop to that environment, and then be able to decide if they want the application in-process or not, with the same interfaces, if at all possible. There a pros and cons to in-process, though. For example, for most web servers, if you put your application in-process, it must be thread-safe. In addition, application bugs have a significant effect on other users (if any) of the web server. The separation you get from keeping your application in a different process gives you a bit more flexibility. You can also turn this around, and, instead of inserting your middleware (and application) into an HTTP server, you can "bolt" an HTTP server on the side of your middleware, making it its own server. This application model (lots of application-specific HTTP servers) also has its appeal and promoters (people who sell them, at least). I think, in the end, web developers need to make their choices based on the middleware that serves their needs, and push the supplier of that middleware to provide flexibility in execution environments. George (speaking for myself, not my company) --- George M. Feinberg Phone: 617-674-5359 Object Design, Inc. FAX: 617-674-5459 25 Mall Rd. gmf@odi.com Burlington, MA 01803-4194 > > Steve > > > -------------------------------------------------------- > Technology Briefings Client/Server Solutions > > T/SA L t d. > > Information Architecture WWW + Database Integration > > tsaltd@panix.com > (212) 343-0209 > --------------------------------------------------------- > >
Received on Wednesday, 18 September 1996 12:08:46 UTC