Subject | RE: [IB-Architect] Extending SP lang. to ISQL |
---|---|
Author | Leyne, Sean |
Post date | 2000-05-15T17:13:13Z |
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.
Sean
-----Original Message-----
From: Doug Chamberlin [mailto:dchamberlin@...]
Sent: Monday, May 15, 2000 12:42 PM
To: IB-Architect@egroups.com; IB-Architect@egroups.com
Subject: Re: [IB-Architect] Extending SP lang. to ISQL
At 5/15/00 12:01 PM (Monday), Tim Uckun wrote:
server
at all.
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.
------------------------------------------------------------------------
Best friends, most artistic, class clown Find 'em here:
http://click.egroups.com/1/4054/4/_/830676/_/958408758/
------------------------------------------------------------------------
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com
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.
Sean
-----Original Message-----
From: Doug Chamberlin [mailto:dchamberlin@...]
Sent: Monday, May 15, 2000 12:42 PM
To: IB-Architect@egroups.com; IB-Architect@egroups.com
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 amodified to
>lot great middleware solutions available. I suppose IB can be
>call out to an external exe or something but this would have to be doneYuck! I agree with Bill Karwin. This stuff should not be part of the
>carefully it's a huge security risk.
server
at all.
>I think a robust language for stored procedures and udfs is a greatthing
>but you have to draw the line someplace sooner or later. It seems to mething.
>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 theWhat about defining an architecture which provides for server companion
>potentially dangerous things and plug it into the database.
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.
------------------------------------------------------------------------
Best friends, most artistic, class clown Find 'em here:
http://click.egroups.com/1/4054/4/_/830676/_/958408758/
------------------------------------------------------------------------
To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com