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	 ! 		      !
+-------------------------+------------------------------+--------------------+