Hello, I'm in good mood as always even if my words seem harsh. It takes an
inordinate effort to make me to catch fire, so you can trust that I have the
head cool yet.

This is Helen's naive charter for this list:
===
Description.
This community is an IBDI forum for discussing details and issues regarding
the architecture of InterBase - classic versus superserver, as well as the
implications of IB's multi-generational architecture.
===

I ask publicly Jim and ISC people (starting with Ann, of course) to help
redefine the objective of this list. This way, we'll avoid one of the causes
of clashes here.

First, let me say I've seen Bill, Jason, Dalton and Jan's postings defeated
quickly because they seemed not to pass some unclear and unstated
requirement in this list.

Second, for anybody is evident that the number of people actively
participating has lowered. Maybe the only exception is the ODBC driver
thread. Not every person wants to get beaten and bashed and ridiculed
because his/her mind is not binary-aligned with either ISC people or Jim
himself. And please consider that nobody outside ISC (except former
employees) has seen the code, so this is an important disadvantage when "us"
the outside world make statements or suggestions.

Third, if there's any predefined format for submissions, then please make a
very rigid web form that should be filled and sent automatically to
IB-Architect but put all of us customers and IB-enthusiasts in read-only
mode in this list, so we can post only through the web form.

The purpose of this list clearly is too broad as stated that it should be
restricted to avoid more misunderstandings. I think that clashes are a fact
of life (so I don't intend to slash them) and some Greek philosopher said
once "the light is born from the discussion". But discussion is different
than battle and even if hard clashes happen and even if they are necessary,
they shouldn't be the modus operandi of this list.

Jim stated a while ago (when he bashed some guy early in this list due to
assumptions on internal index structure) that the purpose was to share
opinions and learn about IB internals and db design. Well, if one, to post
here, should have an university degree on database design (assuming it
exists) or at least 15 years of experience building research or commercial
relational engines, please let me know ASAP to avoid sending any other
email.

People that feel offended because they are asked for clarifications should
reconsider their position. People (excluding Jim) whose only purpose here is
to defeat others' opinions because they feel happy or smart doing so, should
reconsider their position, too.

I agree wholeheartedly with Chris that the horse should pull the cart and
not push it from behind. I'm subscribed to a publication from ZacCatalogs (a
compilation of third party Delphi/BCB components) and I've seen several
packages for sale that are clearly A SOLUTION LOOKING FOR A PROBLEM. I don't
welcome this approach. (For example, if someone asks for IB to include
S.M.A.R.T. support to detect possible HDD physical crashes I even won't
bother to answer, because this is a task for another layer, either the BIOS
or a driver in the OS.) However, if I'm sure my horse will be killed here,
no matter it pulls or pushes the cart, before giving it an opportunity to
demonstrate if it can move the cart in an acceptable way, then I would never
contribute my horse to the guaranteed sacrifice, it's so easy. The objective
of rules, including those in engineering is to aid humans to shape ideas and
things. They day people are slave of rules, then we are dead. The future has
been shaped many times by people who broke rules. Isn't that Jim himself
broke known database implementation rules in the '80s with blobs and
internal shadowing to produce the MGA? Creativity cannot be hampered by too
many restrictions.

It has been said that IB-Architect is not a support list. However, exposing
current limitations first (as the rules mandate) would shift this list
towards almost tech support issues that would have to be skinned to see if
they qualify to be continued here or not. On the other side, Jim, where do
you draw the line between keeping the purity of the original IB design and
simply demoting others' suggestions because they lack all the consistency
you want? I consider this a fundamental point to know the underlying
objective of this list. Certainly the engine design has proven to be ahead
of its time in some aspects, but it's showing its age in little things like
saving up to the last byte in space now that storage is much cheaper than 20
years ago. Examples: the metadata counter in tables and the fact that above
127 generators in a db, disaster happens. In both cases, from an outside
observer's perspective, the problem seems to be that even if the field that
keeps those numbers is smallint, the internal usage of them is one byte
only.

One way to manage the "proposition chaos" here would be to start discussing
limitations v/s needs in IB-Priorities, then with the blessing of Ann or
Charlie, the issue is moved to IB-Architect for further discussion.

Another way to avoid discussing perceived limitations that are only the
result of features that remain undocumented, is to stop further
argumentations until the full API is made public. For example, this weekend
I found an unused.txt file in a 1.44 MB diskette from 1995, containing a
procedure that uses a string variable to compose a message then invokes
post_event with that variable. I had forgot completely this issue because I
feared it could break the engine and also, since I never could make events
work on MS-Win31 networks, I abandoned them. Furthermore, I never knew how
to wait for an event whose pattern is
CONSTANT_STR || ' ' || variable_str
unless the lower level event API calls (as I understood from Jim, they
exist) are able to deal with it. This is one example where perhaps total
disclosure of the API may be the cure.

Being a loyal customer is not the same than being a fanatic. I won't cross
the barrier to become a fanatic. I do free support in the NGs, I run a
webring for IB, I suggest IB against my clients preferences, etc., but I
cannot close my eyes and go to the street repeating a thosand times that IB
is perfect. Also, to lower arrogance, I should remember readers that we are
discussing a product that regardless its technical merits, has a really
insignificant market share in the whole pie (and the only time it received
press attention was when Borland announced they will open source IB), so a
battle here is like watching with a lens how two ants fight. Hopefully, as
more IB-related sites appear, the current state of being an almost unknown
product can be alleviated a bit.

I don't get upset reading flames. I only get bored after 10 or more of
them. BTW, if you want to flame me either here or privately to dissipate
energy, no problem, I read ALL responses. Keep the head cool, ladies and
gentlemen.

C.
---------
Claudio Valderrama C.
Ingeniero en Informática - Consultor independiente
http://members.tripod.com/cvalde