thiagom is currently certified at Journeyer level.

Name: Thiago Macieira
Member since: 2000-03-26 23:56:42
Last Login: N/A

FOAF RDF Share This

Notes: OpenPGP key: DSA 6EF45358 50D5BE34. Fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358.

Well, I am a programmer. Not a big programmer like some people I have found here, but, still, I know how to code.

I was the head developer of an ircd on an IRC Network. But the network has shut down. Currently I am a KDE developer and am the current responsible for networking code in the core libraries.

Where you can find me:
On DALNet, you may find me under the nick FAdmThiago. On Freenode, I'm thiago (thiagom too).

Recent blog entries by thiagom

Syndication: RSS 2.0

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.

25 Jan 2003 (updated 25 Jan 2003 at 12:03 UTC) »

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

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.

8 older entries...


thiagom certified others as follows:

  • thiagom certified acme as Journeyer
  • thiagom certified thiagom as Apprentice
  • thiagom certified Eitch as Apprentice
  • thiagom certified claudio as Apprentice
  • thiagom certified kojima as Master
  • thiagom certified carmstro as Apprentice

Others have certified thiagom as follows:

  • thiagom certified thiagom as Apprentice
  • acme certified thiagom as Journeyer
  • rbp certified thiagom as Apprentice
  • Eitch certified thiagom as Apprentice
  • claudio certified thiagom as Apprentice
  • chaos certified thiagom as Journeyer
  • maluco certified thiagom as Journeyer
  • ralf certified thiagom as Journeyer
  • jarod certified thiagom as Journeyer
  • pasky certified thiagom as Journeyer
  • lmvaz certified thiagom as Master

[ Certification disabled because you're not logged in. ]

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!

Share this page