Sunday, December 20. 2009
However, there have been other major changes as well, including:
The very rough plan for the future is to add authentication support in 0.4.94, and displaying carets and selections of remote users (all protocol code is already there, all that is left to do is to draw them into the TextView) and self-hosting for 0.4.95 and 0.4.96.
The downside of this release is that it breaks compatibility with earlier releases, especially libinfinity 0.3.0/Gobby 0.4.92. I am sorry; I know this is annoying, but maintaining backwards compatibility is as well, and my excuse is that Gobby 0.4.9x is still experimental. It allows me to concentrate more on the interesting stuff. However, if it is not too much trouble then I will try to keep compatibility for the next release. For Windows users it should be very easy to upgrade since an all-in-one installer is provided. Philipp Kern promised to get it soon into Debian and Ubuntu, so I hope the compatibility break will not cause too much trouble. Our public server on gobby.0x539.de runs 0.4.0 already. None of us is using Mac OS X (anymore), so we can't provide binaries for it, unfortunately. If anyone creates a nice bundle, we would be happy to distribute it on our website.
I also want to express my thanks to Gabríel A. Pétursson and Benjamin Herr who made significant contributions to this release. Beginning from January, Benjamin Herr will be paid by the KIT's department of computer science to implement SVN integration and LDAP authentication, so these are likely to be available in one of the future releases as well.
In another related note, the Gobby IRC channel moved to #infinote on freenode.org a few weeks ago. Actually we wanted #gobby which was already registered earlier though, however #gobby was registered earlier already even though it is unused nowadays. We try to get through the FreeNode bureaucracy to get the channel dropped, but it seems that this may take several months, if not years.
Sunday, October 19. 2008
Look at this screenshot of the recently released Gobby 0.4.90. See that nice yellow arrow in the toolbar? Yes, this means we finally have Undo/Redo support. It was a really good feeling having closed bug #39
Gobby 0.4.90 is the first release in the 0.5 series, and 99% of the code have been rewritten from scratch. It is not yet 0.5.0 since it does not yet contain all the features that previous versions had (for example, it does not yet support self-hosting or password protection). However, removing the integrated chat was a design decision, since there are so many other possibilities for communication, including VoIP. As it supports removing documents, only use it with people you trust enough not to delete all your data.
Gobby 0.4.90 does no longer use obby or net6 as backend libraries doing the hard work, but libinfinity, implementing the Infinote protocol. libinfinity is not yet stable API and ABI wise, and probably will not be for still some time. libinfinity contains a dedicated server, called infinoted that Gobby 0.4.90 can connect to.
You can safely install the new version since it is parallel-installable to previous Gobby versions. But please consider everything as very experimental. Things may crash or otherwise behave badly. Report bugs if they do. We set up a playground server on dalaran.0x539.de if you want to test the new version without having to install server yourself.
Thursday, October 9. 2008
I was curious where most time in libinfinity, Gobby's infinote implementation, is spent. Not because it was too slow or something, but just because I wanted to know. So I used valgrind's callgrind tool to gain some profile data while running libinfinity's main test for the concurrncy control algorithm. When I displayed the result in kcachegrind (there is still no GNOME equivalent, no?) everything looked as I would have expected, until I noticed this line:
This means that 14.5% of the overall program time is spent in g_type_instance_get_private(). This is because libinfinity uses g_type_class_add_private for every class to store its members into, so it is easy to extend functionality later without breaking ABI. However, this also means that for every function that needs to access a member, g_type_instance_get_private() is called. I didn't expect such a huge impact, though.
To fix this, I added a simple gpointer to the public instance struct, and let it point to the private field in the instance_init function. So this means one call to g_type_instance_get_private() per instance, instead of roughly one per call to a function operating on an instance of the class in question. After doing this for the five classes suffering most from this, g_type_instance_get_private does no longer show up anywhere near relevant in kcachegrind.
I'd like it if improving performance was always as easy as this.
Tuesday, June 17. 2008
Gregory Haynes is working on Kobby featuring collaborative text editing in your favourite KDE text editor as a GSoC project. He started to wrap the (still unreleased!) libinfinity (my infinote implementation) API for C++ for this task. I'm really excited to see other collaborative text editors coming up that work together with Gobby, since this is exactly one of the reasons why I took the burden to write the library in GObject-based C.
Speaking of which; I didn't blog on it for a long time. We have moved to git in the meantime. I'm currently working on porting Gobby to use libinfinity instead of obby, heading towards a first usable release, so that the hard work pays off. There are still some things in libinfinity that need to be fixed (performance issues, a few known bugs and way more testing) which are probably easier to fix when a usable Gobby version using it exists. I hope to have these done in a few months, though the most difficult part is always to get the little details right, which is probably why I'm not good at meeting (self-set) deadlines.
Monday, July 16. 2007
Many people using gobby complain that it does not support Undo, and some do not even use it therefore. Of course, they are right. It is not only convenient but may also save you lots of data in case you accidentally delete it. However, it is not easy to implement it in a collaborative editor because between your own do and undo operation pairs others might have altered the document. It is thus not reverted to a previous state as with a single user editor. We got suggestions to add some sort of "primitive" Undo like just undoing the last operation, no matter from whom it was. I didn't like that, though, because I prefer to either do things correctly or not at all.
Fortunately, other people also thought about how to achieve collaborative Undo. I read some papers  describing an algorithm (adOPTed) that not only achieves convergence, meaning that two users don't end up with a different document after having applied some operations concurrently (which the obby algorithm (called Jupiter) obviously also achieves), but also allows Undo/Redo (which Jupiter does not when more than two users are involved). This is however not the one-and-only solution. There are other approaches to collaborative Undo (or resolving collisions in general), like the AbiCollab one. adOPTed has some nice properties though:
However, as always, everything has its price:
My proof of concept featuring Undo and Redo is here. However, you probably won't understand the interesting part of that code without having read the papers referenced above (which you should do as well if you are interested in more details, by the way). There a still a couple of issues before that can be used in a real-world environment, though. I think the performance problems mentioned above can be fixed by caching transformed requests, so that it does not have to compute the same requests all over again. Another problem that needs to be solved is a dynamic amount of users. My test code only works for a fixed number of users. The difficulty is to find out when it is safe to forget about operations from a user that has left the editing session, to save memory and bandwidth.
I hope to get that done really soon now so that it can be used in Infinote and perhaps even Gobby (I have not yet decided whether I want to implement that in Gobby because it is still a considerable amount of work).
I am off to Ireland at the 23th of July and am visiting some friends near Osnabrück right after that, but when I am back home (presumably at 12th of August) I really hope to get something usable (read: a gedit plugin) before my third semester at university begins in October. Unfortunately, I cannot make it to GUADEC this year because I have to be at university that week, but I really look forward to finally get there next year.
 Achieving Convergence with Operational Transformation in Distributed Groupware Systems (by Abdessamad Imine et al.)
Sunday, May 27. 2007
Today, I read the GtkSourceview 1.90 release announcement on gedit-list. After having finished my math excerises much earlier then expected I decided to hack GtkSourceview2 support into Gobby. I committed it a few minutes ago into SVN, after having received some advice from Yevgen Muntyan to get it to work (You have to associate a style theme by hand to get highlighting, which will hopefully be changed in the future so that a default theme is used if none is given).
Monday, May 7. 2007
Gobby development has not stalled. We released 0.4.3 with native Avahi support a few weeks ago. However, it is not planned to add any great new features in favor of the sequel I already announced half a year ago. Unfortunately, it does not make as much progress as one could expect it to do, and especially not as much as I would like it to do. My second semester at university began three weeks ago, so I also don't think I get too much done in the following two to three months, either.
The successor of Gobby is going to be called Infinote. It will offer some (long-requested) features the current Gobby architecture does not support, such as different document types, XMPP-based messaging and showing remote cursors/selections. However, the fundamental change is that I want to provide a kind of framework rather than an editor, and to get people to implement Infinote support into their editors so that ideally you can just continue to use your favorite editor for collaborative work. For this to work, I need to properly document the API and network protocol which is also one of the points Gobby is rather weak in currently.
A propos protocol: More and more collaborative editing efforts pop up lately, like Pisara Editor, AbiCollab (which I should really try out in the near feature...) seems to be mature and a GUADEC session description mentions some gedit/collab (over which I did not find out any further details, though). Then, there are of course ACE and MateEdit which I am already aware of. All of these (including Gobby) use different protocols, and are therefore unable to interoperate with each other. Most seem to agree that XMPP is a good base, but there is still the application-specific stuff on top of it that needs to be compatible. It would be great if there was some project like freedesktop.org to agree on a standard for collaborative (text) editing.
The current Infinote code is available in a public SVN at svn://svn.0x539.de/inifinote for those who want to have a look at it. However, most of the ideas do only exist in my head by now and are not written down somewhere in there.
Tuesday, April 10. 2007
Do you remember back in school when you learned stuff you certainly would not need anymore in your future life? I thought the same thing when we programmed things in Delphi (those things actually were quite interesting, though). After Phil poked me once again yesterday, I finally decided to fix long-standing bug #145. So, guess what, the setup system we use (InnoSetup) is not only written in Delphi but also allows custom Pascal Code to be executed during setup. So this is what I came up with, and it would certainly have taken me some more hours if I did not know Delphi before.
I wonder however whether I will have to use Java for some real-world application one day. I would be nearly as good prepared as I was for the Delphi task.
Thursday, March 8. 2007
We released Gobby 0.4.2 today. It does not support that much new features, but fixes some annoyances people have complained about: The urgency hint (the window flashing when a user wrote something in the chat) is configurable, documents can be subscribed to by double-clicking them in the user list and the editor tries to keep the line you are currently editing at the same position within the viewport if others add or remove lines elsewhere.
Sobby, the dedicated server, supports initial loading of regular documents instead of serialized obby sessions. Just pass them on the command line as with sessions, sobby will detect whether its a session, and if it is not, it will open it as a document. Sobby now also allows autosaving individual documents into a directory, via the
Grab them on the Downloads page on our wiki.
Furthermore, I will attend this year's FOSTEL on April 4-5 to represent Gobby there (Thanks to Openismus for making this possible). So if you ever wanted to talk to one of the Gobby developers, be sure to meet me there.
Friday, September 22. 2006
The current draft for the new obby protocol plans to use a peer-to-peer-like mechanism for transport via jabber, so every jabber participant talks to other jabber participants directly instead of tunnelung through the publisher. This should reduce bandwidth usage quite a lot but raises quite a few other questions regarding peer-to-peer: Could new users join the obby network via any peer instead of just the publisher? Could the session stay alive when the original publisher leaves? I met Phil yesterday and we discussed these questions, and we even came up with some results. But first of all, what are the problems?
As soon as every peer in the network is allowed to accept new peers, we have to handle the case that two peers join the same network via two different nodes at the same time.
As a last case, imagine the original publisher has left the session. In the flavour of a real peer-to-peer network the session would just go on as if nothing had happend. The only problem that could arise is that the publisher must not use the session ID that this session had for other sessions, because he cannot be sure that the old session with this ID might still be running somewhere. As sessions are identified by publisher and a session ID this could lead to conflicts. An easy approach would be to just generate a 32 bit random number as the session ID and assuming that we never generated this one before, but I do not like these approaches that only work in 99.999% of all cases and not in 100% (maybe just because I saw it too often that a mage in Wesnoth missed three times...). Having an ID counter somewhere in the user's home directory is not enough as well because another user might publish a session on the same port and with the same ID as another user on the same host (or just use the same jabber account). As above, I am open to any suggestions regarding this point.
Note however that these are just ideas and no final decisions and they only apply to the jabber communication level. All TCP communication is done as Server/Client as before because it is not guaranteed that all TCP participants can get direct connections to each others (think of NATs, different subnets and so on). This also means that Obby currently relies on all jabber users having direct connections (well, direct as in "I just need to send it to the jabber server and the other one will get it eventually").
Wednesday, August 16. 2006
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:
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:
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.
(Page 1 of 1, totaling 11 entries)
Syndicate This Blog