23.03.2016 11:01, Dmitry Yemanov wrote:
> 1) No need to care about that tag -- simplify life for both end users
> and connectivity layer developers.
>
> 2) Explicitly declare our UTF8 only future (in advance).
I would prefer a brand-new API for that, not just a little hacking of old
crap.
--
23.03.2016 12:56, Dimitry Sibiryakov wrote:
>
> what will be an advantage of the new DPB version except implicit isc_dpb_utf8
> tag?
1) No need to care about that tag -- simplify life for both end users
and connectivity layer developers.
2) Explicitly declare our UTF8 only future (in advance).
23.03.2016 10:53, Dmitry Yemanov wrote:
> I didn't not suggest to remove/deprecate older DPB versions, so legacy
> clients will be supported.
Ok, but what will be an advantage of the new DPB version except implicit
isc_dpb_utf8 tag?
--
WBR, SD.
23.03.2016 12:25, Dimitry Sibiryakov wrote:
>> If we agree to move towards UTF8 in the long run, adding a new DPB/SPB
>> version may be a good idea. Not necessarily in v4 though.
>
> Completely break backward-compatibility is a bad idea.
I didn't not suggest to remove/deprecate older DPB
23.03.2016 10:18, Dmitry Yemanov wrote:
> Please let's avoid choosing bad names. It has nothing to do with
> filenames. It should be something like isc_spb_utf8_data or
> isc_spb_utf8_strings instead. And yes, we need to add a properly named
> alias for isc_dpb_utf8_filename too.
I agree that
23.03.2016 12:10, Alex Peshkoff wrote:
>
> isc_spb_utf8_filename is enough, see no need to have new version.
Please let's avoid choosing bad names. It has nothing to do with
filenames. It should be something like isc_spb_utf8_data or
isc_spb_utf8_strings instead. And yes, we need to add a
23.03.2016 12:04, Mark Rotteveel wrote:
>
> In that case wouldn't it be better to bump the SPB version and declare
> that from that version strings buffers are UTF-8 only?
Shouldn't this idea be adapted for DPB as well?
Dmitry
On 03/23/2016 12:04 PM, Mark Rotteveel wrote:
> On 22-3-2016 15:10, Alex Peshkoff wrote:
>> On 03/22/2016 04:54 PM, Jim Starkey wrote:
>>> On 3/22/2016 8:33 AM, Dimitry Sibiryakov wrote:
Hello, All.
Because there is nothing like isc_spb_lc_ctype, must be established
23.03.2016 10:04, Mark Rotteveel wrote:
> In that case wouldn't it be better to bump the SPB version and declare
> that from that version strings buffers are UTF-8 only?
It will add more problems with backward-compatibility with no gain.
--
WBR, SD.
On 22-3-2016 15:10, Alex Peshkoff wrote:
> On 03/22/2016 04:54 PM, Jim Starkey wrote:
>> On 3/22/2016 8:33 AM, Dimitry Sibiryakov wrote:
>>> Hello, All.
>>>
>>> Because there is nothing like isc_spb_lc_ctype, must be established a
>>> rule for
>>> determining of encoding of all
22.03.2016 16:31, Mark Rotteveel wrote:
> Sounds like a hack, why not just introduce a lc_ctype spb item for
> consistency?
I would like on contrary declare isc_dpb_lc_ctype deprecated.
Problem is that Firebird charsets match neither system locales not code
pages. It
causes a big problem
Sounds like a hack, why not just introduce a lc_ctype spb item for consistency?
Mark
- Bericht beantwoorden -
Van: "Dimitry Sibiryakov" <s...@ibphoenix.com>
Aan: "For discussion among Firebird Developers"
<firebird-devel@lists.sourceforge.net>
Onde
22.03.2016 14:54, Jim Starkey wrote:
> I don't agree. It would be better all around if everything passing over
> the wire is passed as utf-8.
I agree here, but I'm talking about API level, not engine internals, so
> all character code translation be handled on the client
> side as part of
On 03/22/2016 04:54 PM, Jim Starkey wrote:
> On 3/22/2016 8:33 AM, Dimitry Sibiryakov wrote:
>> Hello, All.
>>
>> Because there is nothing like isc_spb_lc_ctype, must be established a
>> rule for
>> determining of encoding of all strings passed into services and back. I
>> suggest to
On 3/22/2016 8:33 AM, Dimitry Sibiryakov wrote:
> Hello, All.
>
> Because there is nothing like isc_spb_lc_ctype, must be established a
> rule for
> determining of encoding of all strings passed into services and back. I
> suggest to use
> following:
> If isc_spb_utf8_filename is
On 03/22/2016 03:33 PM, Dimitry Sibiryakov wrote:
> Hello, All.
>
> Because there is nothing like isc_spb_lc_ctype, must be established a
> rule for
> determining of encoding of all strings passed into services and back. I
> suggest to use
> following:
> If isc_spb_utf8_filename is
Hello, All.
Because there is nothing like isc_spb_lc_ctype, must be established a rule
for
determining of encoding of all strings passed into services and back. I suggest
to use
following:
If isc_spb_utf8_filename is included in SPB, all strings are supposed to be
in UTF8.
17 matches
Mail list logo
