Continue draft on the Matrix GLib SDK
This commit is contained in:
parent
c6dccbb22b
commit
51546634e1
@ -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.
|
Loading…
Reference in New Issue
Block a user