> Joseph: can you narrow your expectations and proposed solutions to a

degree

>that doesn't demand 15 years of future effort?

Claudio, Remember... Think OPEN SOURCE. There is no limit to community
effort, and what you can do when you have the whole world... The only upper
limit of Open Source is VISION. That's what I'm trying to say.

My guess is IB Object-Oriented will not be very hard to do. For one thing,
(I think), BLR has the basic capacity to do Object-Oriented "emulation" even
now.

>I have nothing special
>against your ideas, but again let's go back to the horse-before-cart level:
>what are your immediate and most tiresome activities that drive you nuts

and

>that can be addressed maybe in a few months of development?

That's precisely this. REPETITIVE CODES, triggers with exactly the same
bodies, requiring only different headers. This is probably because my
object-oriented mindset - due to using UML analysis makes it such that I
begin to notice so many similarites.

Come to think of it... the POSITION feature of the trigger can even be used
in object-oriented techniques later.

> For example, if you do a task from 40 triggers that do the same thing and
>you would be able to write code like this in every trigger:
>execute procedure generic(current_relation, old, new)

exactly. Again, the analogy of ROLES. Before, when IB did not have roles, we
were content with having EXECUTE procedures granting privileges to
individual users. But now that IB has roles, would you go back to the same
execute procedure?

In my opinion, the implementation of Template Triggers can be similar to
roles. Have a template trigger, and these template triggers can be
referenced by Utilizing tables. (I'm using Utilizing to highlight the fact
that at present, triggers are singularly and statically linked to a table...
which in my opinion will soon get out-moded. Utilizing means, triggers
should have a looser, more dynamic attachment to tables. They should be more
like TOOLS and USED_BY relationship rather than an OWNED_BY relationship
with tables)

> As Fabricio Araujo wrote in IB-Conversions, MsSql procedures are already
>somewhat unreadable. IB procedures have a clean and easy syntax instead.
>They can be learned by newbies in short time. Please, don't destroy their
>beauty with a lot of radical changes in the syntax.

By analogy... COBOL looks beautiful. How would you compare it with C++. Or
even Delphi? I guess beauty and use is in the eyes of the beholder.

> Each time a product receives a ton of new features in a row, disaster
>happens. Borland had to learn that lesson the hard way when they

compromised

>the stability and credibility of Delphi (gained with D3) due to a really
>horrible D4 release. Thanks to that, I lost 2 good client companies; they
>migrated to VB because D4 was virtually unusable when it was released =>

bug

>over bug. We don't need to repeat the story. Being cautious is not
>necessarily the same than being conservative and obsolete.
>

REMEMBER... INPRISE WON'T BE WRITING THE NEW IB CODE. WE WILL BE!!! THIS
COMMUNITY!!!

> In other post, you wrote:
>
>> Lastly, other database servers are going object-oriented to eliminate the
>> impedance between object-oriented analysis (like UML) and database
>> implementations like IB. (Oracle already has object-oriented features).
>
> The last time I checked Oracle's OO features (v7.X) they were more
>marketing than reality.

7 is a pretty old number, I agree. Check out 8.0.5 or 8.1.5.

> It seems like you haven't worked with OO databases. In early 1996, I
>abandoned IB to pursue the mythical aim of developing ....

Point taken. Similar experience... and sacrifice.

>code. That language would be Java probably (I would prefer C++, but...)

me too... but Java is quite okay. I'm using it now to program handhelds
(development stage)

> Disclaimer: I'm not saying Joseph's ideas are useless or totally out of
>context. But I want to draw a line among features on the engine and

features

>on external tools.

I can only offer Professor Nozaki's 3 points for development.
1. What do we want? -- Look as far as you can/ as high as you can.
2. What do we have? -- What are our resources. Can we do it.
3. What can we do? -- Task list. Day-to-day.

It would be clear from these three points that if you start only at number
two, the community will be doomed to obsolescence in a few years time.

I would certainly want to revive that Gung-ho, non-conformist attitude that
the Young Bad Wolf had that pushed him to go beyond the limits of his day,
and realize that there is a way out of those oppressive locks, so that
readers need not lock out writers.

We have new challenges today. Are we content of looking back at yesterday's
triumphs? Or do we forge ahead?

If we want to forge ahead, I would suggest that we seriously look at the
present (very rapid) advances of ANALYSIS, and think about IB
IMPLEMENTATION. That's how IB could leave the pack behind. (I'm thinking of
developing something like Rational Rose for IB)

It is time to get back that LEGACY of 'NO LOCKS' instead of timidity.

Joseph Alba
jalba@...