Marcos.Nobre@... wrote:

> Oh, as noise for a thing that exists in many SQLs (databases)
> thereabout !

This is a pretty much standard debate in many areas of computing: do we
accept the unruly mess that the market has evolved, or do we pursue a
formal standard. Both approaches have advantages, you argue for the
first, but ignore the second (you don't even appear to refute it). I
argue for both as, with a small amount of cleverness, they need not be
mutually exclusive.

I propose a means by which both approaches (and therefore their
advantages, in the eyes of those choosing to implement or use them) can
be supported. This approach is a specific example of a broader class of
actions that can be taken to facilitate loose independant collaboration
in almost any software project. This is of particular interest to any
previously closed software project that is becoming open: the particular
benefits of an opensource project flow, in part, from loose
collaboration, an activity which is largely absent from closed projects.
For projects born in an opensource environment, architectural pressures
to facilitate loose collaboration were present from day one, so such
projects tend already have this characteristic. Projects born in a
closed environment have rarely been exposed to such pressures and,
consequently, rarely have this characteristic.

So yes, I agree with you, it is desirable to introduce common
non-standard extensions into Interbase to help people make the
transition, but it is also desirable to maintain the other advantages
that InterBase has already secured, including standards-complying SQL.
What you propose would abandon that.

See the footnote for a scenario that takes another approach to
illustrating what I'm talking about.

> I think that more people leaving another SGDB to come in InterBase, its
> better.
> No ?

Yes, unless InterBase has to destroy some/all of its current advantages
to achieve this. You appear to offer a line of argument which ignores
some of the larger negatives completely. I propose a means of achieving
the best of both worlds.

> If the implementation of a feature helps or does it facilitate that road,
> would
> this be good it is not?

As above.

> Why some people fight in hindering those progresses? Is it technologically
> impossible to do?

You view it is progress. Others view it as regression. If you are unable
to contemplate both viewpoints, your arguments and proposals will be
one-sided at best.

> How much waste does this bring us? ( size in bytes ~ incrise of footprint )
>
> How much cost more 1mb of software intelligence ( attraction, interesting,
> desired) ?
>
> This feature would cause confusion to (destroy) the interbase?

These are very small negatives which, as you imply, are not enough to
tilt the argument in favour of rejecting the new feature. But you also
imply, or perhaps assume, that this is the extent of the negative
consequences. In fact, a much bigger negative consequence is the loss of
fully standards-compliant SQL, a loss so large that some might choose
(indeed, InterBase has in the past chosen) to avoid.

There are approaches to accomodating multiple responses to either/or
choices, I propose one such approach. If what I propose is viable (and,
to those who would implement it, acceptable) then this will preserve the
great benefit that InterBase already has whilst facilitating additions
such as those that you advoate. Indeed, it will provide a basis to
immediately defuse any future conflict over whether or not to add such
features, those that want them can have them. Those that don't, need not
accept the risk of unintentional dependence.

- Raz

A footnote: One of many infiltration strategies for Linux is the "there
are bigger brothers available when/if we need to scale" story. Suppose
that you are building an ecommerce environment and you really don't have
a reliable estimate of what the workload will be in 12 months time.
Perhaps it will be 10 transactions per second, perhaps it will be 10
000. At some point along that continuum, NT will become a liability. The
solution? Enterprise-grade UNIXes (Solaries, etc.). The problem? That
transition is painfully expensive and so frightening that it is usually
ignored until disaster looms. If you can communicate the idea that
building on Linux in the first place is not only cheaper, less
time-consuming and more likely produce a better result, but that
explosive growth can be accomodated with ease by just shifting to
Solaris over a weekend (yes, I'm simplifying), rather than the complete
rewrite that a shift from NT would tend to require, than the decision
becomes a no-brainer.

An RDBMS that is opensource, runs an many platforms and accepts only
standard SQL, so those evil, careless web-programmer guys can't
unintentionally introduce vendor-dependant code, provides a similar
safety-blanket for a project sponsor. I see Interbase filling this role
beautifully. "No, we don't need to outlay all that money now for a
complete Oracle installation, plus the expertise to run it, we can build
on InterBase for free, have much less administrative overhead and defer
the decision to move to a bigger RDMBS, perhaps indefinitely." Indeed,
my expectation is that indefinitely will be the common case. Obviously
for-money RDBMS vendors are not blind to this line of reasoning and all
provide cheap/free light-weight versions of their products for exactly
this reason, but they do it in the hopes of selling their bigger product
for a profit. Consequently, (a) lockin is beneficial for them, they
don't and can't go out of their way to make it easy to move to other
RDBMSs and (b) there is tension about what features to provide
cheap/free, the more that are provided, the less reason that there is
for customers to pay for the bigger product. InterBase has neither of
these requirements, so it can fill this safety blanket role in a way
that for-money RDBMS-baby-brothers simply cannot.

This is an advantage that I believe that InterBase would be foolish to
give up.

(This has become a rant, there is lots more to say, I'll stop now.)