`The future of (G)obby' by Armin Burgmeier
==========================================
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 developed 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 upgraded. 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 possibility 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 adjustable at run-time 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 eventually even part of
GNOME. This is why I am going to try to build an obby plug-in 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.
--
To unsubscribe, send mail to [EMAIL PROTECTED]
