| Subject | Vulcan services part II |
|---|---|
| Author | Arno Brinkman |
| Post date | 2006-05-10T21:35:40Z |
All,
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?
Regards,
Arno Brinkman
ABVisie
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
General database development support:
http://www.databasedevelopmentforum.com
Firebird open source database (based on IB-OE) with many SQL-99 features :
http://www.firebirdsql.org
http://www.firebirdsql.info
http://www.fingerbird.de/
http://www.comunidade-firebird.org/
Support list for Firebird and Interbase users :
firebird-support@yahoogroups.com
Nederlandse firebird nieuwsgroep :
news://newsgroups.firebirdsql.info
[Non-text portions of this message have been removed]
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?
Regards,
Arno Brinkman
ABVisie
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
General database development support:
http://www.databasedevelopmentforum.com
Firebird open source database (based on IB-OE) with many SQL-99 features :
http://www.firebirdsql.org
http://www.firebirdsql.info
http://www.fingerbird.de/
http://www.comunidade-firebird.org/
Support list for Firebird and Interbase users :
firebird-support@yahoogroups.com
Nederlandse firebird nieuwsgroep :
news://newsgroups.firebirdsql.info
[Non-text portions of this message have been removed]