I have always liked the idea of a stripped down version of IBO... or have
the bpl broken up into parts!!

I presently mainly only use the data access components and not the visual
components. I prefer to display my data in ways that the visual components
usually don't handle well...

Exe size is an issue, just did a small test and the linker does a good job
of cutting down the app size... IBO simple app running a query (no DB UI
components) was 770K IBX doing the same thing was 531. Not a major...

But, it would be nice to have the package bpls split up. My app must use
packages (as it uses dynamically loaded packages and the way it works it
must have package support turned on). The IBO package is 2,400K where as
(from what I tell) the IBX one is only 156K and this includes the services
API stuff that IBO does not implement.

Just some thoughts... from someone who doesn't (often) use all the
features/components of IBO but must use the big bpl...

Regards

Colin


-----Original Message-----
From: Paul Gallagher [mailto:paul@...]
Sent: Saturday, 30 December 2000 9:03 am
To: IBObjects@egroups.com
Subject: Re: [IBO] IBO advantages over IBX

----- Original Message -----
From: Geoff Worboys <geoff@...>
To: <IBObjects@egroups.com>
Sent: Thursday, December 28, 2000 9:30 PM
Subject: Re: [IBO] IBO advantages over IBX


> The core of IBO is very tightly entwined. As witness to this, take a

Wouldn't really matter. The stripped down version only needs to have a very
few lines of code removed. Without those few lines, the rest is worthless.
Also, don't include the form units that are not needed. It would definitely
be more complicated to maintain, but with some compiler directives, and
splitting the directories of the source into a full, and a partial license,
it might not be so bad. The "removed" lines of code could possibly be in an
include file. The stripped version just doesn't get the include files.

Or rather than actually removing any code, maybe there is a way to
cryptically "turn off" the more expensive controls.

It is kind of ironic that the "stripped down" data access components are
actually inherited versions of the "good ones".

I'm certainly not trying to tell Jason how to market his product, because he
knows far more about it than I do. But if this was the reason he has not
offered a stripped version in the past, then maybe it is not as much of a
problem as it seems. Certainly, the stripped version would be much larger
than it needs to be. There would be a lot of code in there doing nothing.
From a programmers point of view, that is awful, but from a marketing point
of view, it is irrelevant.

Paul






######################################################################
Attention:
The information in this email and in any attachments is confidential.
If you are not the intended recipient then please do not distribute,
copy or use this information. Please notify us immediately by return
email and then delete the message from your computer.
Any views or opinions presented are solely those of the author.
######################################################################