11.10.2017 19:47, Vlad Khorsun via Firebird-devel wrote:
I don't see it as a problem, as user already should understand what is connection
string and
how to construct is from host name and database name. From my expirience
"usual" applications
(such as accounting etc) already hide details about connection string from end users.
Tools for
developers, on the contrary, allows to set connection string (among other params), but
developers
should understand what is a host name, database name and service manager name.
So, i see no problem here.
Ok. To make gbak getting backup stream from service for performance purpose you suggest
to change command line options from current "gbak <connection string>" to "gbak <host
name> <database name>" and tell all users that they should understand it, right?
I.e. users will ask you for new version of application, good for you, isn't is ?
No, it isn't. At that point I may be already dead.
There is service connection and there is database connection. This is
different things.
Why they must be different? Services are not goal, it just a tool for working with
databases. Even with the same connection string, they use different API. Isn't this
difference more than enough?
Your proposal hides the difference and just fools app devs.
I would say that it makes using of API simpler.
I see no benefits, just attempt to make a bit complex thing more complex and ambiguous.
Compare this:
fbsvcmgr host:service_mgr user sysdba password xxx expected_db employee action_db_stats
dbname employee
and this:
fbsvcmgr host:employee user sysdba password xxx action_db_stats
What is "more complex and ambiguous"?
Perhaps, you must start to use services API to feel the benefits. As do I.
--
WBR, SD.
------------------------------------------------------------------------------
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
