Claudio Valderrama C. wrote:

>I has the idea from months ago that IscDbc was being pushed as the native
>interface.
>

I toyed with the idea, and eventually gave it up. I think IscDbc is a
wonderful interface, but it's going to take longer than I care to think
about to supplant isc_dsql_whatever. That lead to the idea of a
hard-to-use but common interface.

>
>
>
>> 4. Extensible, efficient, and readily adaptable to the remote
>>protocol.
>>
>>
>
>Ok, but the phrase "primary interface" confuses me:
>- is this the innermost interface the engine will offer?
>

Yes, that is my intention. A "value vector" originates in the client
and works its way into the message as a different type of message, and
back. In specific, the datatype given by the user is maintained from
client to engine. Conversely, a datatype extracted from a record version
will flow back to the client, converted only if the client asks for it
in a different type.

My ambition is a new API will supplant all of DSQL (the calls will be
supported, but through a client side layer). The original BLR interface
will be mainted as a legacy interface.

>- does it affect BLR and or GDML as used in the engine's files?
>

The BLR calls stay. GDML is a client layer on BLR and doesn't exist in
the engine.

>- is this layer only for usage of higher level layers in the server? Can my
>application talk directly to it?
>

Anyone who wants to talk pseudo-objects is welcome. Your application is
more than welcome. But just like BLR, I don't expect you to like it.

>- does this interface offer thread safety?
>

Yes. The primary API will be thread safe with no restrictions on
threads vs. sessions. For what it's worth, this is also true of
Vulcan. Two threads are perfectly welcome to fight over parallel calls
to isc_receive. Which one wins is a race condition, but nothing will be
lost or corrupted.

>>The process that I believe leads to good design has these steps:
>>
>> 1. There is agreement on requirements. This is too often skipped.
>> Without a clear understanding of requirements, there is no way
>> to judge a prospective design.
>>
>>
>
>The horse has always problems when pushing the cart...
>

And a horse is a refined sort of ass.

Believe, Claudio, it's easier to agree on how to get someplace when
everyone wants to get to the same place.

>> 2. An individual produce a design. Or maybe two or three
>> individual produce independent designs. I don't like design by
>>committee
>>
>>
>
>Doesn't this model fit a private corporation more than an open source
>project? It assumes one or two gifted people are the ones with the exclusive
>right to show the path to the rest. Also, if we agree to your vision, then I
>see nothing bad with people doing a prospective implementation of something
>and then offering it to the project, as Alex did some days ago in devel.
>

There is a huge problem when somebody presented something he or she has
already implemented. The issue becomes protecting an investment in code
rather than ideas. Ideas are cheap; implementation is expensive.

Another way to look at it is that it is *always* better to take the risk
up front. In any project, open source or (think carefully, Jim), uh,
other, the biggest risk is that you've overlooked a problem or a
potential shortcut. Discovering that after the fact makes everyone one
-- implementor, critic, and maintainer -- unhappy in the short, medium,
and long term.

Talk is cheap and email is free.

>> 3. Prospective designs are weighed against the requirements. This
>> often leads to a restatement of the requirements and an
>> iteration (this is a very good thing). Problems are found,
>> imaginations are kick-started, alternatives proposed.
>>
>>
>
>This is a luxury for an open source project. The marketing dept at a
>commercial entity won't allow this to go further, as the number of
>iterations may be big.
>

Marketing at Interbase reported to me.

DEC developed a low end graphic terminal called GIGI. Among a number of
serious problems, the microcode didn't implement Vt100 split screen
scrolling, so it couldn't run the VMS EDT editor. I argued with the
project manager long and hard that if it couldn't run the editor, it was
useless. He said it would take 6 months to remask the ROMs and they
would lose $6,000,000 in sales. They made a couple of hundred thousand
and sold maybe a hundred. The computer museum got the rest.

It is better to get it right than to get it wrong sooner.

>This is where heat is produced, but we can't change the second law on
>thermodynamics... ultimately everything degenerates into heat amd heat flows
>trying to produce an uniform, inert state. This explains also why some
>proposals stall.
>

There more inertial in Firebird than any place I have ever worked. Ann
and I talk constantly about the sociology of open source. I haven't a
clue. I am bewildered at my dual role as inventory and chief enemy of
pools.

I try to be open about what I do, listen to objections, explain my
reasoning, change my ideas when appropriate, then fight like hell. If
it were left to a simple referendum, we wouldn't have threads, SMP, or
objects. Next year, these will be like motherhood.

I got infinite grief at DEC for pushing relational databases when
everyone knew CODASYL was the accepted commercial standard. I got
infinite grief for designing a system that could support SQL when we all
new that the Datatrieve language (aka GDML) was superior. I got great
resistance on multi-generational concurrency control when every knew
record locking as the way to go. I got infinite pushback from Rdb/VMS
on blobs. I've got a thick skin. I back off when I think I'm wrong.
And I change like a rhino (hopefully a thoughtful rhino) when I think
I'm right. I do assume that everyone understands the issues as well as
I think I do, and tend to assume that someone who doesn't agree or
understand is being venile, which my wife tells me isn't actually the
case, at least not all the time.

>
>
>>I'm perfectly happy to continue the discussion of error reporting in a
>>hypothetic new primary API. I do have a scheme that I believe works.
>>If something better shows up, I'll adapt it.
>>
>>
>
>What's next? Are you going to show some examples related to how the calling
>code would be?
>
>
>

Not right away. I've a lot of wounds to lick and Netfrastructure bugs
to introduce. We've got a merge to bicker about first.

Thanks for the questions.