Armin's personal Blog

Normally we do not do any such trips since my brother and I do not leave with my parents for vacation anymore. But since they took a few weeks off without going anywhere this year and me waiting for my studies to begin (and even my brother who is usually either dancing or hanging out somewhere with his friends every day has now some time, due to summer holidays) we visited the monastery at Maulbronn, near Pforzheim, last Saturday. It looked like the monastery that is part of the school I was going to, but much bigger and more impressive.

Today, we visited an old silber mine located in the Black Forest. I didn't expect it to be that dirty. We had to wear boots, some kind of jacket and a helmet. One really looked like a real miner in this dress. However, I am way too tall for a miner since I always had to bend down when entering a gallery (well, I am only 1.83m, so most had to. Now I know why they often took children for helping out in the mines).

When we saw this lorry (which was, by the way, only decoration; it was too big for the small galleries in the mine) I immediately thought at that clonk loader on which a clonk is pushing a lorry full of gold. The result of my not-so-great image-manipulating skills is that picture on the right. If you zoom out a bit, you do not see the rough edges around the clonk...

The final release of Gobby 0.4.0 is now pretty close. 0.4.0rc3 has been released just recently and fixed a nasty bug that caused desynchronization, meaning that data consistency between multiple users has been lost. Currently, Phil and I perform some minor tweaks like supporting IPv6 in obby (net6 had this capability since the beginning) which seems to work already as we had an IPv6 session yesterday. Some other final fixes include still broken chat highlighting and UI stuff.

The sequel to the current version (currently codenamed obby 0.5, but most likely this will change before a first release to prevent name conflicts with obby <=0.4.0) will be developped in C, not C++. This has several reasons:

• C++ has a quite huge impact on code size. The same program written in C makes the shared library and the executable much smaller. This might only apply to GCC and probably because it links half of the STL into each and every binary, but it hurts when I see that it is not necessary for a working library.
• Binary compatibility is easier to maintain. First of all, net6 and obby made extensive use of templates which caused them to be linked statically into gobby and sobby. With handsight this was not a good idea at all since one always had to recompile gobby when libobby was upraded. On the one hand, I am convinced that API/ABI stability can be achieved with C++ (as gtkmm proves), but on the other hand one has to take very much care. Just adding another base class or a virtual function might break ABI (for example, this is why Gtk::ComboBox does still not derive from Gtk::CellEditable) whereas this would be no problem in C since there are not any virtual functions nor base classes.
• C++ makes it hard to create language bindings. There was already an attempt to create haskell bindings for obby, but it turned out that prior C bindings to the C++ library would have been required. I am however not an expert in this area, so I cannot say for sure whether there would have been other ways, but writing the library directly in C does not make it worse.

First of all, this means a complete rewrite of the library. This is a great opportunity to change the complete architecture. We want to get rid of the classic strict client/server architecture and get more into the peer-to-peer direction. We now follow an approach that kind of mixes both variants. The networking shall be divided into two tasks: Discovery and Transport. Discovery means finding running obby sessions within the network and transport means actual communication during a session.

A session now also only contains only one document instead of an arbitrary amount of documents. Instead, the library allows joining and creating multiple sessions using the same network connection. This reduces the concept of subscribing to a document to just joining another session.

Apart from this, obby 0.5 shall support the following key features:

• Multidimensional state space collaboration algorithm: Multiple two-dimensional state spaces (as currently used by obby) are easier to implement and maintain but cause a loss of data that makes it impossible to implement a proper Undo operation. It is however still very unsure whether Undo will be implemented in a first Version of obby 0.5 because some questions remain still open.
• Enhanced networking: obby 0.5 is going to offer the possibilty to use jabber for networking beyond a local area network. This allows easy NAT traversal with IPv4 and automatic session discovery in a WAN. Avahi will be used for discovering sessions in the local area network, and it is still possible to establish TCP connections directly, as it is still the case in obby 0.4. The only requirement is that sessions discovered via TCP or Avahi must be joined using TCP as transport and sessions discovered via Jabber must be joined using Jabber as transport.
• Display remote viewports, carets and selections: This is one of the most requested features for obby (probably right after Undo...). Whenever the local cursor position, selection or viewport (viewport as in scrolling position) changes, the event is transmitted to others. However, this must be controlled to save bandwidth usage, so, say, only once every 500ms such a request may be sent. This number could also be made adjustible at runtime to reduce latency in a LAN.
• Different character encodings per user: In obby 0.4, an encoding is set for the whole session and all participants have to deal with this. This will not much change in obby 0.5 since Jabber requires text to be in UTF-8, so this will be the encoding used for transport. However, obby is going to perform possible character set conversions by itself when you tell it what encoding you expect. This also allows offsets of insertions and deletions to be given in characters rather than in bytes, avoiding unnecessary calculations from offsets to byte indices and vice versa.
• Record and playback of sessions: Everything that has to be done is to serialize every incoming and outgoing operation with a timestamp included. This allows to go back in a session's history and view earlier versions of the document.
• Read-only users: They would not need an extra dimension in the state space, so apart from a bit more network traffic there is almost no overhead.

Like obby 0.4.0, obby 0.5 should have not that much dependencies (avahi is optional, iksemel is included since we had to apply one or two fixes to it and it seems not to be actively developed anymore). This allows it to be used on a variety of platforms and desktops without being required to use some uncommon dependency (like GTK+ on Mac OS X).

So, these are our plans for obby, but what about Gobby? Well, I also have some changes in mind, although they are even more far away. As I am a convinced GNOME user after all, I would like to integrate Gobby more into the GNOME desktop and become eventuelly even part of GNOME. This is why I am going to try to build an obby plugin for gedit after obby 0.5 has been released. Since we want to collaborate with non-GNOME-users as well, something is also going to replace Gobby as a stand-alone editor. I even consider using wxWidgets to achieve a more native look and feel on the corresponding platform.

However, this is very far away from now. The current obby 0.5 code has about something more than 10.000 lines of code and implements only most of the networking stuff including discovery via jabber and avahi. All those nice features mentioned above still have to be implemented and tested.

Just have look at this screenshot and guess what makes it differ from the developer mode viewport windows in the currently released beta 18.

Nothing? Way wrong: The viewport window is now a full GTK+ featured window instead of just a raw X window. Currently, this makes no difference indeed, but it offers quite interesting possibilities: We could easily add scrollbars to the window, just like on Windows. This not only enables drawing large landscapes without having to drag a player's clonk around to move the viewport's position but due to the main loop still running during scrolling, it would also even pretend the game from blocking (like the windows version does) which is quite annoying when drawing landscapes with others through the network. Well, of course the network first needs to be fixed to stay synchronized with the windows version.

Another possibility the GTK+ window offers is drag+drop of definitions from, say, nautilus, into the viewport with few lines of code and having GTK+ do the dirty work.

As almost everyone has got a blog today, I just thought I needed one, too. Well, here it is. I wonder however how long I am motivated to blog regurlarly...

After having tried Bluetrait first I finally took Serendipity as weblog software because it also runs with the PHP option "register_globals" activated (although it recommends turning it off, and so do I) and I have no access to the php.ini file to turn it off. There seem to exist other methods to perform this (.htaccess?), so this was not the only reason not to use Bluetrait. The major one being that Bluetrait also forces me to use a WYSIWYG editor to write blog entries which I dislike (at least I could not find an option to turn it off).

I still have to figure out how to integrate my other pages like the Term parser and the links into this one before I finally make this blog the main site of arbur.net. And I still need a category where posts like this belong to...

Update: I just created an internet category for this post, although I doubt that many entries will end up in this section.