Continue draft on the Matrix GLib SDK

_drafts/writing-an-sdk.md

@@ -9,14 +9,59 @@ author:
     email: gergely@polonkai.eu
 ---
 
-In the last few months I've been working for a GLib based SDK for
+In the last few months I’ve been working on a GLib based SDK for
 client applications that want to communicate with a Matrix.org
 homeserver.
 
-For whoever doesn't know it, Matrix is a decentralized network of
+For whoever doesn’t know it, Matrix is a decentralized network of
 servers (Homeservers). Clients can connect to them via HTTP and send
-messages (events, in Matrix terminology) to each other. They call them
-events because these messages can be pretty much anything from instant
-messages through automated notifications to files or, well, actual
-events (like as a vCalendar); anything that you can serialize to JSON
-can go through this network.
+messages (events, in Matrix terminology) to each other. They are
+called events because these messages can be pretty much anything from
+instant messages through automated notifications to files or, well,
+actual events (such as a vCalendar); anything that you can serialize
+to JSON can go through this network.
+
+My original intention was to integrate Matrix based chat into
+Telepathy, a DBus based messaging framework used by e.g. the GNOME
+desktop (more specifically Empathy, GNOME's chat client.) After
+announcing my plans among the Matrix devs, I quickly learned some
+things:
+
+1. they are more than open to any development ideas
+1. they really wanted to see this working
+1. they would have been happy if there were a GLib or Qt based SDK
+
+With my (far from complete) knowledge in GLib I decided to move on
+with this last point, hoping that it will help me much when I finally
+implement the Telepathy plugin.
+
+## Matrix devs are open minded
+
+What I learned very quickly is that Matrix devs are very open minded
+folks from different parts of the world. They are all individuals with
+their own ideas, experiences and quirks, yet, when it comes to that,
+they steer towards their goals as a community. Thus, getting
+additional information from them while reading the spec was super
+easy.
+
+## The specification is easy to understand
+
+Except when it is not. For these cases, see the previous point.
+
+Jokes asidu, anyone who worked with communications protocols or JSON
+APIs before can get along with it fast. The endpoints are all
+documented, and if something is unclear, they are happy to help
+(especially if you patch up the spec afterwards.)
+
+
+## Copying the SDK for a different language is not (always) what you want
+
+I started my SDK in C, trying to mimic the Python SDK. This was a
+double fail: the Python SDK was a volatile WiP, and C and Python are
+fundamentally different.
+
+During the upcoming weeks this became clear and I switched to the Vala
+language. It is much easier to write GObject based stuff in Vala,
+although I had to fall back to C to get some features working. I also
+planned and implemented a more object oriented API, which is easier to
+use in the GObject world.