Subject Vulcan services part II
Author Arno Brinkman

We need to come to an working draft, from the previous discussion i had this merged together.

1) Increase subsytem with more calls, so engine can support backup/restore/validate/etc...
Dispatcher should handle the service params and implement services.

2) Increase subsystem with fb_engine_info() method only. fb_engine_info() has dbHandle so dispatcher can lookup provider.
This meant the service needs a dbHandle and could use the one from the SecurityDatabase.
(ps This one is currently never detached, only attached and the dbHandle is assigned to anything).
Every call to fb_engine_info() should be provided by an dbHandle, but this isn't used at all in the final engine self.
Only 1 result from engine is possible.

3) Increase subsystem with fb_engine_info() method only. fb_engine_info() has nodePath (string) which for example holds servername(s) (and engine name?).
Multiple results could be possible and are concatenated. Enginename could support matching characters (fe "server1:eng*").
Services call fb_engine_info without servername and get all the information from the engines configured (in the configuration file by the engines section).

I think 1 will make dispatcher to complex, because it has to implement a service which needs to do many things (think about quering running progress etc..). Also less flexible on the server side.
Beside that it would take a lot of time to re-code a lot of information and Vulcan needs to be finished. I definitly don't go for 1.

Option 2 looks a nice way to handle the problem. The drawback is that you always need to have a dbHandle (you need to be connected) to get information about a engine.
Second problem could be that SecurityDatabase is using different engine as user would like to see, but we can't support multiple info in the services anyway for backwards compatibility.

3 Is also a nice, but dispatcher requires a little bit more functionality. Drawback is that nodePath should be provided and enginename-matching is done in the engine self.
Also the configuration needs to be extended with a section "engines" and method can be called without any database validation.

I'm really in doubt between 2 and 3 as they both have their positives and drawbacks, but so far i tend to go for 2.

Comments please?

Arno Brinkman

General database development support:

Firebird open source database (based on IB-OE) with many SQL-99 features :

Support list for Firebird and Interbase users :

Nederlandse firebird nieuwsgroep :

[Non-text portions of this message have been removed]