Armin's personal Blog

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.