Jason,
sorry for the late reply, but I have been away these days, and I also
wanted to catch up with the messages in this list (which I had not
subscribed to).

> > I didn't say that I mind whether one is better than the other (and I
> > have said that I _know_ IBO is superior under many aspects); I said
> > that, although your licensing scheme is not as restrictive as it may
> > seem to many (and for clarifying that I thank you again), two points
> > must be taken into account:
> >
> > - IBX is the official open source component-based solution for
> > InterBase;
> > - there are areas in which IBX and IBO overlap.
> >
> > If you could demolish these two points, I am more than happy to follow
> > you in your quest.
>
> I fail to recognize the significance here. If people blindly followed this
> model a vendor could provide whatever junk they wanted and people would just
> live with it.

We are not talking about blind people, nor we are talking about junk;
as I see it, there are two competing products in the component-based
connectivity arena and what I would like to know is what the ISC
strategy about that is; it is difficult enough to convince customers to
adopt a data access technology; it beomes more difficult if the
technology is not "officially" recognized or supported by the back end
producer.

> Think of how much this goes on in the M$ realm. I don't know
> about you but there is a reason I am here using Borland development tools.
> Because I believe that we as a community of developers should make
> "official" that which is the best. Rather than letting marketing hype
> determine it. Worrying about what is official is akin to worrying about what
> is hyped.

Value is not that much an issue. As long as two products work at least
decently, it is easy that the "official one" gets used most frequently
by customers.

> I'm not saying they should die a terrible death. I already said that
> anything in them that needs to be added to IB_WISQL (renamed most likely to
> WISQL or something snazzier) and live on in fond remembrance. Nothing is
> dying here... I'm suggesting a merger of the two where IBX will cover the
> services stuff and IBO will cover the data access stuff.

I would like to know, form someone more knowledgeable than me, whether
they think feasible to tie the development of InterBase tools to a
product which isn't open source in theory (it can be free for non
commercial use, we have already said that).

> Rather than me struggling alone with IBO/IB_WISQL and them doing the
> IBX/IBConsol gig we could have worked together and had a lot more to offer
> in one awesome package.

Is it really too late for that?

> > are you suggesting rewriting the tools with IBO? How does that
> > accomodate with the open source scheme?
>
> I'm saying that IBX is bound to Inprise development tools but the native IBO
> architecture isn't bound to Inprise development tools and can readily port
> to other development environments. This will allow the "official" open
> source tools offered by InterBase to be worked on by those in communities
> using non-Inprise development environments. Yes, this implies that there
> will be some work in porting IBO's data access architecture to other
> development environments but I am committed to that effort. All of them that
> I have contacted are excited for this prospect and rolling up their sleeves
> to help. It's going to happen with IBO but it can't happen with IBX.

This does not touch me very much; I am only interested in using Borland
development products (namely Delphi), under Windows or maybe Linux, and
I don't know if I would use InterBase without them. I can see that the
situation you have described can be relevant to some people, but I don't
know how many.

> Well, as long as IBX is still BETA, which it is, I don't see how it can
> *currently* be considered the official architecture of InterBase.

May I remind you that the _whole_ product, as of today, is in beta?
Moreover, Borland decided to release its version of IBX (usable or not)
as part of Delphi 5 and C++B 5 Enterprise, which were NOT marketed as
beta products.

> > > IBX needs to remain focused on the new services and installation API's.
> I
> > > intend on leaving it that niche open for it to grow and flourish in. As
> for
> > > the data access portion, I fully intend to keep the momentum I have and
> > > strive keep it so that using IBO is preferable in every aspect over IBX.
> > > Count on it. Pouring work into the IBX data access layer may very likely
> be
> > > a futile cause since those willing to get involved making contributions
> will
> > > be doing it in IBO because that gets them free licensing and a huge leap
> > > forward in completeness and stability.

I will acquire more information and see what I myself should do about
that; fortunately, the BDE is still at least usable with IB6 and that's
the technology I am recommending right now for old applications; I still
have to decide on what to recommend for new ones, and I believe I must
do it right now; maybe the hints I can catch in this list will help.
--
____
_/\/ando