Going deeper in search for the right thing

I am very good at criticizing things, and after 7 years of being involved in Open Source I have seen many areas of improvement. Of course, the important thing is not to criticize, but to offer solution, and even pursue them.

One of the first serious development I did was on Gaim’s MSN plugin. A very rewarding experience, but the frustration with Gaim’s internal API made me left the project. So I wanted to create an MSN library, this time Done Right™, which in overall meant totally asynchronous.

I started it in C.

Then I realized there was no good enough networking library for me, not really asynchronous. I did an extensive search for GLib based approach and there were not many options: the only viable ones where GNet and flow. I tried to get involved in flow but in the end development staggered.

So I went one level below; I hunted for C based approaches. There are many, but I only liked libevent and liboop but those where not exactly what I was looking for.

So I decided to create my own, but guess what; there’s no good kernel API for AIO. There’s aio, epoll and the recently deceased Kevent.

So I decided to simply use plain old poll. This is how a sample test client looks like:

connection = my_core_new_connection (core);
connection->read_operation = read_operation;
my_core_connect (connection, "localhost", 80);
my_connection_send (connection, "GET /index.html HTTP/1.1\nHost: localhost\n\n", 42);

That’s all I wanted, I don’t have to wait for the server the be ready and then send the data, the library queues the write command, and issues it when the the server is ready. When there’s data ready to be read the library calls the read_operation callback. I just need to call my_core_poll continuously; I did it so I could easily integrate it into other main loops as GLib’s.

I called this library libdsocket, I still have to choose a good name and release it I guess. Anyway I had one piece.

Then came another issue: proxies. Again, there’s no good proxy library.

There are a lot of integrated solutions like libcurl, but that’s not what I wanted. I wanted something isolated, like my socket library. I decided to skip the step of creating such a library, but it turns out that now there’s a neat library to parse PAC (Proxy Auto Configuration) files: pactester. That’s one step in the right direction.

So, finally I did it, well, at leat the first step: libgmsn.

I didn’t really use my sockets library, but something similar. It uses GObject, libxml for SOAP stuff (authentication) and OpenSSL.

It’s a great proof of concept, but it even has my username and password hardcoded (testing account).

But then again, I’m not so sure anymore C is the right thing for something so complicated as the MSN protocol.

Then I found about Pymsn. They are a crew of very cool guys, I tried to contribute but then I found out I don’t like Python that much.

I hanged out in #c a long while, hearing about a lot of programming languages other than C. There is people with a lot of knowledge there, I learned a lot.

I finally decided to try Ruby, and I fell in love.

Implementing the authentication for MSNP15 (not an easy task) and address book handling was a bliss, a total bliss. I have to clean my code a bit, and then I’ll post it somewhere. Maybe once I get my Ruby code for MSN in a good shape and with a design that I really like I’ll decide to port it to C, but I have so few time that I doubt I’ll ever do it.

So, going back to the subject, I think Linux really needs the following:

  • A good isolated, asynchronous and simple networking library in C
  • A good isolated, simple proxy library in C
  • A good AIO kernel API

Let’s consider one use case: I set my PAC in GNOME’s Proxy Configuration, no application can use it because PAC’s are scripts in JavaScript, they’ll have to implement a parser or use pactester. Even if I set the proxy manually each application does their own proxy implementation (Gaim/Pidgin, X-Chat, Evolution, etc.) so each application has different bugs; that is stupid!

Mental note: remember Sammy Jankins and post your code.

Update: Thing, it was thing, not ring.


6 thoughts on “Going deeper in search for the right thing

  1. Hi Felipe! I just came across your post and wanted to point out that Flow development has not stopped. In the end, I gave up waiting for GNOME to move to SVN, and imported it in CVS. It was converted to SVN in October 2006 and lives on there.

    Right now I’m waiting for a reply to a request for a mailing list and bugzilla product on the GNOME servers, but I haven’t gotten a reply since February on that, so I’m not sure what’s happening. I have a plan B, though, and as soon as I’ve set it up, I’ll make a release.

    In the meantime, you’re free to check out what’s in SVN (the code is pretty much finished, including the TLS wrapper, but needs some polish and documentation). Although I guess it’s not an issue anymore, now that you’ve rolled your own 🙂

  2. Hey Hans!

    It’s good to know you are still working on this, it seems like a pretty good idea.

    And what about this GVFS thing. I saw you commented on it, but I don’t rememberer you mentioning flow.

    Anyway, the latest code I could find is the following, which has a few months untouched. Do you have a newer version?

  3. As you’ve noticed, I’m currently working with Alexander Larsson on GVFS, which has a greater focus on file system access, not stream processing, and which will replace gnome-vfs eventually.

  4. Yeap, I’ve seen it, and it’s a step in the right direction. But we still need an IO library that makes use of it transparently, perhaps GIO?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s