Issue Details (XML | Word | Printable)

Key: CORE-5631
Type: Improvement Improvement
Status: Reopened Reopened
Priority: Major Major
Assignee: Alexander Peshkov
Reporter: Dimitry Sibiryakov
Votes: 0
Watchers: 2

If you were logged in you would be able to see more operations.
Firebird Core

Allow isc_info_svc_to_eof be used for sending binary stream to service

Created: 06/Oct/17 02:54 PM   Updated: 10/Oct/17 04:55 PM
Component/s: API / Client Library, Engine
Affects Version/s: 4.0 Beta 1
Fix Version/s: None

QA Status: No test

 Description  « Hide
Currently when backup is restored via services with stdin usage, only isc_info_svc_line is recognized for sending backup data and isc_info_svc_to_eof is silently ignored (which cause endless loop in application that try to use it).
isc_info_svc_line is supposed to be used with text data and using it for binary data is not good from several points of view (EOLN marks, encodings, etc). Binary data is better to be transferred using isc_info_svc_to_eof.
Creating of new info item would be not good for backward compatibility.

 All   Comments   Change History   Subversion Commits      Sort Order: Ascending order - Click to sort in descending order
Alexander Peshkov added a comment - 06/Oct/17 03:09 PM
When backup is restored isc_info_svc_line is used only for monitoring data returned by "-v" switch of gbak which is definitely nothing other than text data. Stdin data passed to service is treated as binary stream.

Dimitry Sibiryakov added a comment - 06/Oct/17 03:15 PM
I'm talking about send_items, not query_items.

Pavel Cisar added a comment - 06/Oct/17 03:58 PM
It's clear that choice to use isc_info_svc_line to mark chunk of stdin sent to service via SPB was not wise choice (to say it mildly). Both isc_info_svc_to_eof and isc_info_svc_line are normally used for service output (query items) and they were created just for that purpose. Using them to identify items going in other direction only caused this confusion. It's pointless to ask that isc_info_svc_to_eof should be supported here as well (as an alias), and it would cause only more confusion as people would expect that they would mean two different things that would work similarly as in query direction (which they can't). In fact id used to send data to restore service has no special meaning except to identify the data chunk (so no EOLN at play here etc.). It could be ANY number devs would choose. Was using svc_line logically correct? No. Changing it to proper one (by logic to isc_info_svc_stdin) would be best, but that would break all existing code. At least isc_info_svc_line has some logic we could live with, but support for isc_info_svc_to_eof alias has no logic at all.