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 server
at all.

>I think a robust language for stored procedures and udfs is a great thing
>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 thing.
>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 stuff
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 directs
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 mechanism.
This way the main server stays lean and mean, as it should be.