Hi Peter,

The Qt docs state explicitly that a conversion to and from UTF-8 takes place. That even seems correct according to RFC-3986:
…
I didn’t find any reference to UTF-8 in RFC-1738 but the query string component of the HTTP scheme should be text. But anyway, QUrl should have provided the option to pass non UTF-8 encoded data.

I think that UTF-8 in the RFC-3986 is correct and it can be there, but as you’ve said, there is nothing in the RFC-1738 about it. The reason why I belive that it shouldn’t be UTF-8 encoded before encoding is that in the BitTorrent specification is the following line:

Some other hash properly quoted looks like this: %04%96%1F%C0%5E1%5D%08%13%81%E3%AF%CC%89%144%A53%06%FE

This hash has exactly 20 bytes and there are values like %FE and that means it wasn’t UTF-8 encoded, because I got %C3%BE with QUrl::toPercentEncoding.

I was actually thinking about using URIs internally in Calitko for all kind of IDs or adresses. For example, NodeAddress could become a URI of the form “tcp:123.123.123.123:1234″, or “udp:…”. Then we could have a TransportFactory which returns a Transport object of the correct type. A similar approach could be useful also for Sessions.

I was thinking about using QUrl for that but maybe we could create our own class Uri. Initially I would just copy QUrl, rename it and add overloads taking QByteArray instead of QString (hope that would not require changing their internal representation). Then we could use class Uri also within the TorrentRequestWriter.

I’m pretty sure that using such a utility class would make the handling in TorrentRequestWriter much easier and would require less code. Let me experiment with Uri and I’ll give you feedback!

Ok! Yes, it would have been much easier using such a class (not only for the TrackerRequestWriter).

We could use types that enforce these requirements: InfoHash, RawPeerId, quin64. The ones that are nulls ( == T()) would be ignored and not appended.

Ok, I’ll use quint64 instead. For info hash we could use something like Sha1Digest (as you’ve suggested). But what about peer id? I got it stored in the PeerInfo class which is only an “improved struct” right now and it doesn’t check its validity.

QCryptographicHash would help us with hashing but it simply returns the hash digest as a QByteArray. It might be nice if we had Sha1Digest, Md5Digest, etc. They could actually just be typedefs for instantiations of something like HashDigest . Then InfoHash could be a typedef for Sha1Digest… just some ideas!

Yes, we should definitely use some abstraction like Sha1Digest, Md5Digest, etc. I was actually thinking about some proper implementation. Qt itself doesn’t offer anything but that QCryptographicHash, so we would need some 3rd party class like http://tamale.net/sha1/, but we should make our own wrapper for it. But maybe you know about something better.

Have a nice day, Petr