I spent all the day yesterday writing an implementation of the current IDN documents. When I was done for the day, I receive an e-mail in kde-core-devel stating that another implementation had been written, using the standard GNU libidn library.

Ok, so I spent the beginning of today changing my implementation to use libidn. At least now that's working and it correctly encodes and decodes any hostname I fed it.

Now I've got to go back to the rest of the resolver stuff. Missing:
- how to find a worker class;
- the workers themselves!
- the manager routines to queue new stuff;
- the Resolver routines that start and stop jobs;
- getproto* and getserv* wrappers

Note to myself: the start routines and the queueing ones can be integrated.

I think this weekend I'll have some more coding time.

I'm still stuck with a question: some resolutions might require another resolution to be done. So, that is, a thread will have to notify the manager that it's done and another resolution must be fired. When that one is complete, another post-processing must be performed. And it must not block a thread.

How do I do that?

I can think of two possible cases for that: one is a simple class that instead calls upon the gethostbyname2_r() resolvers to lookup IPv4 and 6. Another is a SRV-based lookup, that might require several lookups afterwards.

If you didn't know, the code I was referring to below has been accepted and integrated into KDE a long time ago. It was released with KDE 2.2 and has received many a fix since. Not many new features have been added since, though.

However, now I'm in the process of rewriting what I wrote before. This time, it's to fix some of the architectural mistakes I made the first time. And to simplify the whole thing, which is regarded as bloated.

Yea, I agree with that assessment. For instance kextsock.cpp is the third largest file in kdecore.

Ok, now to the new thing. This time, the class KHostname I mentioned two years ago is actually getting written, in the shape of the KDE::Network::Resolver (yay for namespaces!). Interesting how things wound back to haunt you a few years later, ain't it?

I've started the process this time by writing text describing what would need to be done and getting peer feedback. And still is there the possibility of making this code into Qt.

What is now written: the Resolver API, most of its internals, plus the resolver manager and a few helper classes. The classes that do the dirty work itself are not yet written.

Right now, I'm asking myself the question: how can I make a worker class request another lookup and still be called for post-processing, without blocking a running thread?

Code is here.

I'm still on the same regarding the little project I started.

I got in contact with Martin Konold of KDE and he said he'd give me write access to the kde-core-devel mailing list. Well, I don't know if he got to that or not, because my e-mail seems to be filtered out of KDE's mail server. (must be a rule regarding @mail.com)

So, I'm still waiting for an answer, and it seems people are going on vacations already

Oh, the other idea I had was to create a still new class in kdelibs, called KHostname. Its constructor would receive a text hostname and then someone could call KHostname::lookup() and receive all the data in a QList<KSocketAddress>

Problem: I'd use getaddrinfo() to do the lookup, which would either be:

• a repetition of the code needed in KExtendedSocket to do the same loookup
• called by KExtendedSocket to do the lookup, which in turn means KHostname would need port/services

Given that, I am in doubt whether this class would be better integrated into KExtendedSocket alone.