11.10.2017 22:22, Dimitry Sibiryakov wrote:
11.10.2017 20:57, Vlad Khorsun via Firebird-devel wrote:
I don't understand your speculations
Ok, turn your imagination on: Performance of gbak must be improved by feeding of backup stream from server using services instead
of sending queries. How will you implement it?
IIRC, it is already implemented. And i see no relation with a way to set
connection string here.
If you need to implement new service action - define it parameters, as usual,
and implement it.
Where the problem ?
Because someone at IB times made decision that service connections is not a
database
connection. And i must agree that service could work with some database. Another
service could work with two databases and third service could work with no
database
at all (read firebird.log, for example). As expirienced user of ISC API you
should
know it.
No, I have no idea what service can work with two databases. Currently there is no one able to do that. Even multifile restore is
impossible with using of services.
So, turn your imagination on. Service *is not a database*, is it clear ?
Service could
make any kind of job, it is not bound to any database.
Every service action have set of parameters. In your second example i see no
paramenter
for action action_db_stats. This is not that kind of simplicity that i would
ask for.
action_db_stats requires no parameters.
It needs to set database name to gather stats from. Since Firebird is a DBMS
(note
first letter), many services works with databases (surprize) and uses some
common
parameters for its actions. But it doesn't mean that action_db_stats requires
no parameters.
A little for you to know: isc_service_attach() and isc_service_start() is
different routines
and requires different set of params. More, you may call isc_service_start()
many times within
the same service connection, AFAIU, and i see no reason to limit all the
service tasks by the
same database.
I used it as the shortest example. If you insist on longer one, here it is.
Compare
fbsvcmgr.exe host:service_mgr action_nbak dbname employee nbk_file employee.bak
nbk_level 0
fbsvcmgr.exe host:employee action_nbak nbk_file employee.bak nbk_level 0
And what is the best: both these commands works and do exactly the same. No
old functionality is broken or changed.
So why do you need second one if it the same as first ? To save few pressing
of keyboard ?
And you consider it as "technical" reason to fool app devs ?
To finish with it: you make proposal and ask for objections, i gave you
objections,
what else do you want ?
If you forgot: I would like to hear technical problems that you foresee with proposed changes, not "I'm fine with current way, no
need to improve anything".
I already told you that hiding one entity by another one is very bad idea.
And there is no improvement in your proposal.
And you don't read what i wrote.
As expected.
Vlad
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel