> -----Original Message-----
> From: Firebird-Architect@yahoogroups.com
> [mailto:Firebird-Architect@yahoogroups.com]On Behalf Of Helen Borrie
> Sent: Viernes, 22 de Julio de 2005 1:54
>
> Agreed - Jim, do you have some wires crossed here? Your suggestion was
> aimed at a mechanism to report the attributes of the database
> engine, i.e.,
> presumably a service call of some sort; but then you proceed to suggest
> that it could be a *database* info structure. Why would you write the
> engine capabilities into databases? Isn't it the ODS level that matters
> when considering what a database can support?

Because he's trying to solve a chicken and egg problem: to handle a
database, the y-valve should poll all available providers until one says "I
can take this db". We won't continue maintaining a single provider to handle
all historical ODS because it's nightmarish practice. Therefore, until a
provider is loaded and connected to the db, you really can't ask for the
capabilities. Ultimately, the capability depends on which provider is
selected which depends in turn on which ODS the database is using. No db
connected, no provider loaded, no capabilities available.

Otherwise, we should consider a special call that can return the
capabilities of the newest provider the y-valve can find, requesting that
such provider handles databases directly instead of being a gateway to
something else.

Does this make sense to you?

C.