Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!apple!voder!blia!miket
From: miket@blia.BLI.COM (Mike Tossy)
Newsgroups: comp.databases
Subject: Re: Parsing Query Languages in the Client or Server
Message-ID: <9580@blia.BLI.COM>
Date: 4 Oct 89 18:04:59 GMT
References: <6155@sybase.sybase.com> <6167@sybase.sybase.com> <3715@rtech.rtech.com>
Organization: Britton Lee, Los Gatos, CA
Lines: 31

In article <3715@rtech.rtech.com>, news@rtech.rtech.com (USENET News System) writes:
> In article <9463@blia.BLI.COM> miket@blia.BLI.COM (Mike Tossy) writes:
> >Final note: parsing on the client does NOT mean you can use a dumb terminal
> >connected directly to a server.  You still need "smarts" on the client end.
> 
> Uh, nothing precludes having 'smart' front-ends which can trap lexical
> errors, if not some semantic errors, and dumb terminals which cant.
> Scanning/parsing could be a run-time negotiable parameter determined
> between the client and server.  If the client is dumb, then the server
> has to run the 'front-end' smarts for him on the back-end.
> 

(Did I miss the joke?)  This is not called client/server this is called
traditional software rdbms.  It is possible but it is undesirable for
all the usual performance reasons that caused companies to go to client/
server architectures.  Your "server" would also need to run programming
interfaces and 4GLs etc, etc.  Looks like a time shareing system to me.
If you need to connect dumb terminals connect them to a little UNIX box
and have it talk to the server.

--miket

Mike Tossy                                      ShareBase Coropration
miket@blia.bli.com                              14600 Wichester Blvd
(408) 378-7575 ext2200                          Los Gatos, CA 95030
					(Formerly: Britton Lee, Inc.)
					 
The preceeding might be (probably is - in fact) close to the opinion
of ShareBase Corp; but if you think I bothered to clear it with anybody
other than myself you're crazy.