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
_______________________________________________
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
