Subject RE: [IB-Architect] Extending SP lang. to ISQL
Author Leyne, Sean
Aren't we now in a discussion about the definition/distinction of the IB
engine and the "server application" layer. Where does one stop and the
other start?

Bill Karwin, is correct when he suggests that the IB engine should be
focused on core functionality.

There is, however, a very strong and valid point for suggesting that new
functionality should be provided.

Doug, your suggestion about a "server companion" implies that it's an
add-on. I personally see it as more "core" to the product (a wrapper
around the engine). I would have no issue with different "flavours" of
wrappers - the current lightweight and the "new" heavy-duty
super/scheduler/batch/batch data import/export processing.


-----Original Message-----
From: Doug Chamberlin [mailto:dchamberlin@...]
Sent: Monday, May 15, 2000 12:42 PM
Subject: Re: [IB-Architect] Extending SP lang. to ISQL

At 5/15/00 12:01 PM (Monday), Tim Uckun wrote:
>Why not use IBPERL or java or something on the server side? There are a
>lot great middleware solutions available. I suppose IB can be
modified to
>call out to an external exe or something but this would have to be done
>carefully it's a huge security risk.

Yuck! I agree with Bill Karwin. This stuff should not be part of the
at all.

>I think a robust language for stored procedures and udfs is a great
>but you have to draw the line someplace sooner or later. It seems to me
>it's better to take the Postgres approach and make it a pluggable
>Take an open source language, make slight mods to it to get rid of the
>potentially dangerous things and plug it into the database.

What about defining an architecture which provides for server companion
processes? These would run on the server alongside the main server
process(es) and would be responsible for script executions or other
which should run on the server machine?

Perhaps ISQL could be expanded to direct certain tasks to a companion
process via a pre-process dispatcher. I don't know how the server
incoming requests but it seems that early in the process it would be
feasible to direct a certain type of ISQL operation/command to another
running process and use the TCP/IP connection as a pass through
This way the main server stays lean and mean, as it should be.

Best friends, most artistic, class clown Find 'em here:

To unsubscribe from this group, send an email to: