Soweli Lukin


The Urbe Project: back to C

Although I criticize the Web a lot, I must confess we aren't going to get rid of it in the near future. And, it's important to say, THERE ARE a lot of things there that actually are kind of cool...

Now, I started a Youtube channel some days ago. It's named "til cleber", that, in Portuguese, means "tilde cleber": a reference to "~cleber". (It also contains a pun, because the name sounds just like "uncle cleber", too). And I'm talking, guess what?, about how the Web missed the target about The Unix Philosophy and some ways we could have done better.

https://www.youtube.com/channel/UCTVu-cjuBp1cbAMvMd5UuVw (I speak in Portuguese in the videos and there are no English subtitles...)

In the next video I'm going to introduce my ideas about an alternative protocol I'm working, named "Urbe". That's Latin for "city" or "town" (and the root for the word "urban", for instance). Its components obey the following scheme I'm going to draw while my dog sleeps under my desk with its head laying over my right foot...

URBE:

+-------------+
| Vila        |
|             |
| [Locus]----------- Via ---------[Hospes]
| [Locus]     |
| [Locus]     |
|             |
+-------------+

I purposedly avoided common nomenclature, because I want people implementing it to dissociate this scheme from the Web. But, if don't know any Latin, here comes some legends relating both protocols/environments/technologies:

Urbe -- Web Vila -- Server Locus -- Site Via -- HTTP Hospes -- Client/Browser

That is enough details for now. The thing is: it must follow the Unix Philosophy, so we're not going to have A Big Server Implementation communicating with A Big Browser Implementation. It MUST be composed of small applications, preferably pre-existing ones.

So, starting with the Vila (the "Server"), the first thing to implement is a connection handler. It must accept a lot of simultaneous connections and call proper programs to handle each one. I even thought about using netcat (nc), but it is not built as a multi-connection manager. In the end, having not found a nice alternative, I'm writing my own connection handler from scratch. In C.

Fact is, I know C. I knew it very well less than 10 year ago, but I'm using basically only higher level languages, like Python and shell scripts, for such a long time, that I kind of lost the hand in writing C programs, even a simple one like that.

Interestingly, I'm trying to grasp this skill back NOT USING THE WEB. So I'm guiding myself, when possible, only with man pages (mostly level 2). I'm still stuck on Linux (I confess I'm not smart enough to learn too much new stuff at the same time, so I'm delaying my plans of learning OpenBSD and Jehanne OS for my own mental sanity sake), and now I can see some man pages are kind of very wanting.

I tried to implement the triple socket, bind, accept only reading man pages, but the trick about opening an AF_INET stream socket (the very common TCP/IP connection) was impossible to get from them. I had to appeal to the Web to discover accept had two NULL arguments...

I believe C is one of the languages that separate The True Programmer from the most common "programming language user". Hell, C is THE language The True Programmer must master at all. BUT, i must confess: it's not a "sane" option for most of the needs people have nowadays. I'm happy to see a lot of progress on Rust (that I believe is becoming the natural C successor for "system programming") and Go (that I believe is becoming the natural C successor for "apps programming"). I'm very, very interested in implementing something using both of them.

I'm kind of planning on trying Nim, too, although I have some bad feelings about it after reading the "usage" documentation on the language website: it feels very, how could I say? "Windows-ish" or something like that. And the compile-to-Javascript thing doesn't help that much, either...


Soweli LukinIssuesAlex Schroeder