Hi Tim,

Tim Uckun wrote:

>
> This would be very nice indeed. OTOH it sounds like you are describing a
> middle layer too. Why not keep the engine simple and pared down. Write you
> middle layer application in whatever you choose and send XML to the client.
> You could even do it with a web server what serves XML only.
>
> The server side needs to be flexible enough to deal with all the data (see
> NULLS) but other then "plugging in" languages maybe it's the best way to go.

I used to do this with some specialty programs I used to use before I
became aware of IB.
When I started with database work, SQL was still one of many protocols
(and I did not believe it would become a standard). Middle tier was not
a 'new' approach to programming, because most of the time, it was the
'only' approach to client server. Novel networks and arcnet made lan
bandwith precious (everyone today is complaining about getting software
like IB working on dialup connections, 2 Mb arcnet or (heaven forbid) 1
Mb baseband networks were far slower when they got busy than any 14Kbs
dialup)

The database at that point was simply an agread upon storage format that
the client service processes accessed. (Classic style IB is this model -
you can write software that runs on the server and directly touches the
gdb without the need for inet_server)

If you look at IB, it should still be looked upon as a middle tier
solution. It should be looked upon as THE middle tier. You have your
data residing in files. You have a series of programs that touches the
physical database so your program does not have to.

The big difference is, IB was designed with more power than any of its
competitors at the time. Instead of a simple api with basic data
retrieval services, IB was originally desinged to handle business rules
via selectible stored procedures and a trigger hierarchy that made it
extreamly feasible to perform extensive data validation/manipulation
with ease.

What I am stating is that, we already have the middleware. IB IS THAT
LAYER. All I am putting forth is that we should recognize this and
extend it to handle more things.

It would be interesting to look at the code. It would be curious to see
if it is possible to strip IB into multiple layers that could operate on
different machines.

ie.

Client side api - a simple wrapper to ease connecting to the database,
very little processing involved except for (perhaps) a data
compression/encryption algorythm.
This would sit on the users machine.

Client Services Service - This is the workhorse of IB. It contains all
the parsers, blr compilers, query optimizers, triggers etc.
When a user goes to connect to IB, they specify the server that is
running this code.
They also specify another machine (relitive to this machine) that is
holding the data.
The data could reside on the same machine, or on multiple machines or in
multiple GDB's.
The Client Services Service would not have any physical access to the
database, but would generate the plans and correlate the results before
sending them back to the client.

File Services Api - This is a slave process that would be controlled by
the Client Services Service. It's only job is to manipulate data on a
local file following strict instruction from the CSS. It does not run
any SP code or do anything else, just optimize for storing and
retrieving data.


This is not a wish, please do not take it to be anything more than food
for thought, but, we may find, as more and more developers want to
access more than one GDB for queries and server side code, we may find,
that is the road IB may take.

This is not a bad thing, just perhaps a further evolution of what IB is.

best regards

Dalton