| Subject | Re: PS about client-to-FBcore protocols regarding charset, #5. |
|---|---|
| Author | the_a_rioch |
| Post date | 2012-06-29T12:32:09Z |
Hmm... this is my new hypothetical proposal.
Previous mail was where i repeated and assessed 4 proposals i stated earlier (i called them approaches) during the thread.
Did Yahoo just deleted that post without sending it ? Or some antispam alerted to some stop-word ?
Pity, but be it...
To much personal for today.
Potentially even protocol might be turned into some kind of EBML or XML/binary stream with DTDs defined for each version of client/server.
I am not concerned about long-distance limited-bandwidth or paid-per-traffic connections though i agree there probably are people who use it.
Old Windows and old Delphi would probably be used with old server and are out of scope.
Also don't forget that since Delphi 2009 it is already using UTF16 (or maybe UCS-2) strings. So currently all modern Delphi users do conversion SBCS string to Unicode and back. Now they would convert Unicode to Unicode. Big deal ;-)
what i found completely wrong direction, is when client tells server "NONE" while really treating them "WIN1251"
It is MySQL way, to INSERT NULL value meaning that is PK to be auto-incremented. That works. Locally. But not in long term.
Previous mail was where i repeated and assessed 4 proposals i stated earlier (i called them approaches) during the thread.
Did Yahoo just deleted that post without sending it ? Or some antispam alerted to some stop-word ?
Pity, but be it...
To much personal for today.
> fbclient.dll,Surely if ever done, that would done in both client and server simultaneously and only engaged if they both are capable of it.
Potentially even protocol might be turned into some kind of EBML or XML/binary stream with DTDs defined for each version of client/server.
> > This way you would have the most efficient network throughput.It was told that UTF8 is bad charset for default network connection for in worse case it would sent 4 bytes instead of 1.
>
> That is not the philosophy behind the FB.
I am not concerned about long-distance limited-bandwidth or paid-per-traffic connections though i agree there probably are people who use it.
> It would require your Delphi installation to depend on ICU libraries,Modern Windows do have their own unicode databases.
Old Windows and old Delphi would probably be used with old server and are out of scope.
> - All clients are able to consume data in UTF-8. Period. All DelphiThe would not. Conversion would be encapsulated either inside fbclient.dll or at data access components level.
> users will cry when they start to convert Unicode strings to SBCS and back.
Also don't forget that since Delphi 2009 it is already using UTF16 (or maybe UCS-2) strings. So currently all modern Delphi users do conversion SBCS string to Unicode and back. Now they would convert Unicode to Unicode. Big deal ;-)
> - All clients get what they ask for. Those asking UTF-8 get UTF-8, those....but they should ask.
> asking WIN1251 get WIN1251, and when umlauts are stored - they get an
> error "Cannot transliterate characters between character sets".
what i found completely wrong direction, is when client tells server "NONE" while really treating them "WIN1251"
It is MySQL way, to INSERT NULL value meaning that is PK to be auto-incremented. That works. Locally. But not in long term.