Thanks for your thoughtful comments. This probably had better be the last
post on this in the architecture list as it is digressing into marketing
stuff. I'm CCing the IB-Marketing list so we can move over there to continue
those aspects.

> > but
> > there are other very important aspects that need to be considered here.
> > There are many benefits to using the native IBO data access architecture

for

> > this over IBX data access... I'll explain. (beware of ramble)
>
> 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. 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.

> > I suppose some IBX'ers could scramble and try the catch-up game with IBO
>
> You are talking about a game I am not interested in; in my opinion, the
> better the tools, the happier the programmers. I am a programmer and I
> can surely benefit of IB_WISQL (despite the name - have you thought
> about giving it a more commercially sound one? ;-)), but I have to say
> that your advice to use IB_WISQL and let WISQL/IBConsole die a terrible
> death is not a good one; OS InterBase needs OS tools, and third parties
> (like you) are welcome to produce better tools. This is the way I see
> things currently. IBX could surely be deprecated in favor of IBO, but I
> don't see it a reasonable thing just because IBO does not come directly
> from InterBase (see later).

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.

> > but
> > the only thing accomplished there would be to put me out of business and

end

> > up with nothing better after a ton of hard work. I'd rather that effort

be

> > directed into making what is already great, better. I think the

InterBase

> > community would also be better off if I didn't have to take my talents

and

> > skills elsewhere. Cooperation is far better than competition in this

arena.

>
> I fully agree; I couldn't see how your initial post in this thread was
> about cooperation, though.

Well, I guess I have to confess that I am still harboring some hard feelings
towards InterBase for not realizing the value of the IBO offering and the
generosity of the trustware licensing and take on a more cooperative stance
towards my efforts. Actually, if I even felt like I had been given a decent
opportunity... but that's all water under the bridge. Instead of cooperating
with me they shanghaied FreeIB and embarked on a path competing with IBO.
I'm saying that it would have been much better if InterBase had
cooperatively collaborated with me instead making this mess come about.
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.

> 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.

> Your point is clear; as I said in my previous post, I wanted to know
> whether IBX was the official architecture (as it seems today) or not; if

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.

> I understand you right, the game is open about that, and thye community
> will state what the better tools are. Is this right?

I think this is the way that it should be in an open source community. We as
a community should be looking to support the best product rather than
waiting and expecting someone else to give us the "best" product. Now that
InterBase is open source it's us as the community that is going to have to
carry the development effort so ought not we get to determine what we are
going to work with?

> Personally, I will try to do my best to make the better prevail (still I
> see it as a competition thing rather than collaboration...).

Yes, I'm stuck in the past as I said. For now it is a competitive position
that we all need to deal with until resolved.

> > 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.
>
> You are foreseeing a future in which the two products will complement
> themselves, is this right?

This would be my preference. Have IBX focus on areas that I clearly am not
inclined to go into and leave off the "competitive" endeavor to duplicate
what I have in IBO.

I'm not saying that IBX data access be totally abandoned either. It is
obviously at a usable state for some things. If IBX is good enough for some
brain-dead simple stuff then people ought to be able to use it for that if
they want. But if they have something fairly involved or need critical
stability and such then they should not struggle and strain to try and get
IBX working to that level and just use IBO instead.

And, if neither product does what someone needs or wants then IBO ought to
be the target for those enhancements because it is best that one product
remain a complete subset of the other in the areas where there is overlap.
That way people will know when it is time to move to IBO if they are
outgrowing the IBX model. I think the "Trustware" licensing model is worthy
of that.

If the IBX model is expanded and too few move to IBO as a result then the
IBO option may eventually be terminated and I'll be out my investment in the
IB community...

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com