>> If former - we don't need PROVIDER clause then - it should be part of
>> Firebird. BTW, we don't have clause to register provider :)
>
> Because we don't need it. If provider will be regular Vulcan-style provider
> it will be registered in appropriate config file

Do you want to implement ODBC, JDBC or other adapters as providers in
Vulcan architecture?

>>> 2. Login mappings management
>> User name/password is not enough, we have to support certificates at
>> least. I think we should split security part into another thread.
>
> While i agree that we may discuss security separate i not agree we _must_
> support anything except password. If we will support certificates - good. But, please,
> not require it

No, I do not require it, I just say that we have to consider the PAM
architecture Alex wanted to implement. The mechanism should be easy to
extend with other exotic things like single-signon, etc.

>> That means that external tables has to be defined in the database
>> explicitly. As to the explicit queries - if they are used often - people
>> can define them as views (finally - as selectable procedures, add syntax
>> extension to CREATE PROCEDURE statement).
>
> This way is used by ASA. I very very not like it. It is hard in use and require many
> efforts from end-user.

Can you provide a list of problems with this solution? Why is it hard to
use and what exactly efforts are required from end-user (not database
developer/administrator)?

>> I do not consider the cross-database queries as something that should be
>> very flexible - at the end it is about integrating two databases, not
>> about acting as router to another DB.
>
> I not agree with you here. As for me cross-database queries must be as easy from
> end-user POV as usual queries

Who is end-user in our case? Software developer or user of the software?

>>> It is necessary to think up a way to set an external table name with its full qualification by
>>> external engine rules. it is possible to quote full name but it is easy may not fit in ours 32
>>> symbols and it is not clear how to quote external quoted identifiers;)
>>>
>>> Also such names will not fit in SQLDA. The truth, it not problems for work with external FB
>>> data source.
>> If we extend the CREATE TABLE declaration as shown above, this problem
>> disappears - it will use local identifiers.
>
> This is the only positive i see in extending CREATE TABLE :)

Well... if you have a better idea to handle long tables names from other
database engines in XSQLVAR without changing the XSQLDA version or API -
I'm all ears :)

Roman