Jim Starkey wrote:

>>
> Claudio, thanks for the history lesson. I think we agree that process
> is as important as detail, especially in an open source project with
> creative people of strong will.

Vlad had since then pointed out that the city couldn't be St Petersburg but
Moscow, just for the record.

> But let me give you a recap.
>
> Sometime back, I said that I though we needed a new primary interface
> to replace the dreadfully inefficient DSQL interface. I believe I
> said
> that the requirements for the new primary interface should be:
>
> 1. Callable by most languages, i.e. 'extern "C"'
> 2. Supports the existing DSQL interface as a layer
> 3. Supports the existing IscDbc interface as a layer

I has the idea from months ago that IscDbc was being pushed as the native
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?
- does it affect BLR and or GDML as used in the engine's files?
- is this layer only for usage of higher level layers in the server? Can my
application talk directly to it?
- does this interface offer thread safety?

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

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

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

> 4. The design iterates until the designer is convince it is
> complete
> 5. The project does a final analysis with a thumbs up or a thumbs
> down.

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

> I think discussion of the requirements and important characteristics
> is useful, healthy, and will lead to a better design. When I propose
> that design, it will be a design that I believe meets the
> requirements, the desired characteristics, and is internally
> consistent. Then we pick it apart.
>
> 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?

C.