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

Reply via email to