Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!lll-winken!sun-barr!newstop!sun!amdahl!rtech!news From: news@rtech.rtech.com (USENET News System) Newsgroups: comp.databases Subject: Re: Parsing Query Languages in the Client or Server Message-ID: <3715@rtech.rtech.com> Date: 28 Sep 89 02:30:21 GMT References: <6155@sybase.sybase.com> <6167@sybase.sybase.com> <1989Sep24.215650.15732@odi.com> <9463@blia.BLI.COM> Reply-To: pasker@rtech.com (Bob Pasker) Organization: Relational Technology, Inc. Lines: 26 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. A logical extension (in my (warped, networking) mind) is to have a pipeline: queries get done in stages: entry, scanning, parsing, execution, etc. There's no reason why these couldnt be done in heterogeneous machines. So lets say you want to run a (text based) RDA front-end against a parse-tree back-end. Stick a parse-server in the middle which takes text in one side and emits a parse tree out the back. Have a parse tree front-end? Point him directly at the back-end. See, isn't networking easy? - bob +-------------------------+------------------------------+--------------------+ ! Bob Pasker ! Relational Technology ! ! ! pasker@rtech.com ! 1080 Marina Villiage Parkway ! INGRES/Net ! ! (415) 748-2434 ! Alameda, California 94501 ! ! +-------------------------+------------------------------+--------------------+