Claudio Valderrama C. wrote:

>>-----Original Message-----
>>From: Firebird-Architect@yahoogroups.com
>>[mailto:Firebird-Architect@yahoogroups.com]On Behalf Of Jim Starkey
>>
>>This is my recommendation on how to proceed post-Vulcan:
>>
>> 1. Build a reusable module that models metadata and can
>>generate SQL DDL.
>> 2. Replace the GBak direct system table updates with this module.
>> 3. Make system tables read only except for internal engine operations
>> 4. Get rid of DYN, MET, and DFW. DDL statements operate against
>> internal data structures that update system tables to reflect the
>> current state.
>>
>>
>
>I couldn't agree more. Hard work that simplifies life when finished. But I
>have questions:
>
>1.- What will happen to ESQL users? Ah, you don't like acronyms. I mean:
>what happens to application developers that preprocess .e and .epp files?
>
>

I don't see any problem at all.

>2.- Does your step 4 imply that all DDL is committed automatically?
>
>

Yes. We find and fix the major components that do direct system table
updates then blow the bridge. This will probably mean that some folks
who took advantage of implementation artifacts will have to do a little
work. That's life in the software biz.

>3.- Is it necessary to get rid of MET, too?
>
>

Necessary? Don't know. Desirable? Absolutely.

I want to eliminate all engine preprocessed modules in favor of embedded
SQL.

>4.- Can we define the core system tables after that? They are a subset of
>the current system tables, but I'm not sure which ones.
>
>

These are serious design questions. We need a design to provide a
context in which these questions can be considered.