On 23/07/2005 10:15 GMT+1, Nando Dessena wrote:

>... Plus, the proposal does not
>address the problem of knowing the capabilities for a database that
>doesn't exist yet. Who should I ask whether I can create a dialect 3
>database or not?
>
>

Why not take the problem the other way around ?
Why would I want to know in advance if I will be able to create a
dialect 3 db or not ?

Application talking: 'The best I could do for my user is to create a
dialect 3 db, so let's try that'.
Engine answering: 'Sorry guy, failed for bla bla reason. For your help,
here is a list of my capabilities'.
So why not return a 'capability list' (whatever form it takes) upon
returning errors ? Or on-demand as suggested by Jim.

The list of capabilities could be updated or added to by the various
plumbing components the attachment traverse. So it is not impossible to
have a piece of code on the application side (built using current
libraries) able to give to the client a list of capabilities for an
engine which wasn't programmed to return you one. In other words, the
sometimes erroneously named client library of version 2.0 linked with my
application could supply me with a capability vector for an older engine
version (1.0 for instance) that never was programmed to build and return
such a capability list. That's one of the beauties of the architecture.

That would fit Jim's architecture where the 'server' is not something
materialized which we should be able to talk to, outside of the context
of a database attachment.

Most 'Services API' functions are database related. See the magnificient
hack named backup / restore and calling gbak for instance. That one does
not need a 'Services API'. Attach to the DB, then using that attachment
ask the server to backup it up. How to restore ? Use a variant of the
create_database(): create_database_from_backup(). You get the idea.

Not having a notion (except the services API hack) of server_attachment
is just fine. It lived well for more than 2 decades.

--
Olivier Mascia