[Interest] QWebSocket text methods should be utf8?

[Roland Hughes]

On 2/15/20 5:00 AM, Jason H wrote:
> After reviewing the QWebSocket spec (https://tools.ietf.org/html/rfc6455  ) text frames are supposed to be UTF-8 encoded, which would mean that QByteArray would be the proper class.
>
> Now I'm having to toUtf8() all the things I receive, and QString() the ones I send. I am sure this leads to some degree of madness.
> I'm wondering if it would be possible to provide proper overloads:
> - sendTextMessage(const QByteArray &message)
> - textMessageReceived(const QByteArray &message)
> - textFrameReceived(const QByteArray &frame, bool isLastFrame)
>
> Because all I ever do is ship JSON data over them, so I wind up doing:
> void  textMessageReceived(const QString &message) {
>    QJsonDocument::fromJson(message.toUtf8()); // seems useless when the data coming in was already UTF-8.
> }
>   - or -
>
> sendTextMessage(QString(QJsonDocument::fromVariant(map))); // Seems like it's being generated as 8, going 16 wide just to be sent out as 8 again.
>
> I could be wrong, but I'm scratching my head on this one.

Ah Jason my friend, please sit down and allow me to tell you a story 
which I believe contains both the answer and the source of your head 
scratching. The problem you are having is that you are looking through 
the eyes of a piece of a dog that is yipping from a porch at all of the 
real dogs running in the street. A piece of a dog, one of those 
Time-Life Books Dogs where another piece of the dog arrives after each 
monthly payment. When you've completed your "easy" 60 or 84 payments, 
you then have a whole dog.

The whole dogs are big. They consume mountains of data in one sitting 
which are larger than any existing city block. They produce piles of 
output so high they cast a shadow over the roof of the two-story house 
having the porch where the yippy-yappy piece of a dog is yipping an 
yapping from.

Not only are the whole dogs big, they are big-endian. Any piece of a 
dog, whether it wants to one day grow into a whole dog or not, has to 
communicate with them if they even want to be considered a piece of a 
dog. The yippy yappy dogs are shrieking loud yet completely harmless. 
Eventually, just to shut the incessant yapping up confusing and 
pointless specifications get created to satisfy pieces of dogs not tall 
enough to see the end of the street.

(https://tools.ietf.org/html/rfc6455  )

They are pointless and confusing because all traffic on the street has 
been and will be world without end big-endian.

( https://tools.ietf.org/html/rfc1700 )

The convention in the documentation of Internet Protocols is to
express numbers in decimal and to picture data in "big-endian" order
[COHEN  <https://tools.ietf.org/html/rfc1700#ref-COHEN>].  That is, fields are described left to right, with the most
significant octet on the left and the least significant octet on the
right.

The QString class, by virtue of the little yippy-yappy dogs it is 
running on isn't big-endian hence your continually calling toUtf8().

The sad reality is not having those yippy-yappy dog pieces of standards 
mandating certain chunks be in little-endian would have made the entire 
communications process and the class API simpler. 100% of the data would 
be in big-dog format so 100% of the time the API could do the exact same 
thing. Now,

No, the yippy-yappy dogs will never change the entire standard. They 
shouldn't have been allowed to introduce the conflicting pieces they did.

I didn't save the links but I also stumbled on some links saying the rfc 
you found is really just a suggestion when it comes to text frames as 
one could indicate utf-16 at the control level.

https://tools.ietf.org/html/rfc2781

If it doesn't help I hope it at least makes you smile.

-- 
Roland Hughes, President
Logikal Solutions
(630)-205-1593

http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog