El verano muestra una resistencia contra llegar en mi región. Que suerte que la Conferencia de Escritorios en Gran Canaria sería organizada cerca de África... en Las Palmas. Como siempre tengo que prepararme un pocito porque la última vez que estaba en España fue en Diciembre, en Madrid. Entonces... ¿que hacer? Escuchando Tropimania 95.1-97.5 FM Gran Cararia el día entero? Leer El código 2.0 que fue publicado sob la licencia CC Atribución-Compartir Igual? O, finalmente, trabajar más en mi própria distribución para ultrapassar los Kubunteros de las Islas? Bueno... siendo un geek, no tengo ninguna excusa por no combinar las tres tarefas :)

Inspired by a feature request for more complex filtering rules, Commitfilter is now able to import CIA XML rulesets. This makes it possible to get all mails related to translations, for example, without auto-committed Scripty mails. You can also subscribe to all commits by myself except when I'm working on playground stuff. Note that the CIA configuration is currently separate from the traditional path/author configuration. It is also not reflected in the live filtering previews. One option would be switch to this rule language entirely and thus be able to export from Commitfilter to CIA again. Let's see how many people make use of this feature before jumping to the next one. Send feedback to kde-services-devel.

In related news, GHNS is being picked up by GNOME developers again. Should give us some interesting material to talk about at Akademy/GCDS.

Historically, the GGZ approach to consistent multiplayer games on the desktop was to offload all the non-game specific tasks like login, chat and game start into special applications called core clients. After a while, this turned out to be a terrific idea but it contradicted the behaviour of most players. Their usual workflow is to start the game first and then switch to online mode rather than the other way around. For some time now, all the necessary components to allow this alternative path have been available for Gtk+ game integration, but no such widget framework has existed for KDE. (In all fairness, the first game ever with embedded core client support was Widelands which uses SDL.)

This is now changing: With the introduction of the classes GameCoreClient and KGGZCoreLayer, games can easily integrate either an off-the-shelf multiplayer control panel with a list of players and running games, or pieces thereof through the lower-level EmbeddedCoreClient class. Both widgets and standard actions like connect to game as spectator or launch new game are supported by this framework. A number of technological goodies like social gaming are thus also becoming available with only few lines of code in the game clients.

Having a strong service-oriented background, my interest in reusable software is rather high. Ideally, most parts in service and component development would be reusable with well-defined interfaces and loose coupling.

In KDE land, we're now forging plans for 4.3 features and are faced with the undesirable dilemma of growing social software on the one hand (good!), but horrible widget inconsistencies on the other hand (not good!). The area of chat widgets is such an inpatient in need of consistency-increasing medication. Chat widgets are used in (drumroll...) chat applications, but also in online games, collaborative text editors and office applications, and just about anything else which has humans connected to it. In short, we do have a need for a chat widget set shared at the kdelibs level to increase consistency and cut down the number of redundant codelines in the already infinitely growing codebase. SoC candidates, anyone?

However, the search for a suitable candidate with a reasonable set of features is not easy. Let's follow good habits here by looking at the candidates:

• KGGZ (part of the KDE3-based ggz-kde-client package) uses its own chat widget based on Qt classes. It offers nickname autocompletion, history, colouring and everything including the kitchensync, but is clearly protocol-specific and would need porting anyway.

• Vencedor (heading towards kdegames) uses the KChat class from libkdegames. It is rather old, not maintained, doesn't look fancy and is domain-specific for games, especially two-player games.

• KBattleship, despite being part of kdegames, uses its own chat widget! It's rather small and not nice or featureful, but at least it's generic.

• Kopete uses its own chat widget which is rather flexible and full of cross-protocol features, including spell checkers and whatnot. According to its developers it should be possible to make it reusable by relying on the libkopete interface, but so far this still resides in kdenetwork and won't move due to ABI compatibility concerns. There are some interesting ideas currently being discussed, though, so it could still be possible.

• Quassel uses its own chat widget. This IRC client receives a lot of developer and user attention at the moment, but according to its developers is not easily reusable.

Let's also follow really good habits by looking at the friendly competition:

• Gobby uses its own chat widget based on GTKmm which is clearly Gobby-specific. It provides history, but no nickname autocompletion or emoticons.

• GGZ-Gtk uses XText, the quite reusable XChat widget, which has almost all of the features one needs. However, the last time we merged the latest XText codebase, a lot of compiler warnings and some errors were introduced and have been there ever since. Not sure if XText is still maintained at all.

• GGZ-Java uses its own chat widget based on AWT/Swing which is clearly GGZ-specific. The features are certainly sufficient for online gaming, and it's stylable with CSS. And, oops, I just spotted a bug where it assumes the name of the chatbot to always equal "MegaGrub".

To summarise, most people like to reinvent the wheel, and despite having been one of them in the past I'd like to see some consolidated generic chat widget becoming available to any KDE application.

Last Friday, January 30, Dominik Haumann and me went from Darmstadt to Frankfurt am Main to join the KDE 4.2 Release Party in the Brotfabrik. It wasn't the biggest such event, but had a nice mix of users and contributors, of locals and guests.

I had my N810 with me, which was unfortunately out of battery that evening, as well as a similarly-spec'd subnotebook which proves that the latest KDE compiles and runs just fine on a 400 MHz processor with 256 MB RAM. Not fast as light, but a lot more usable than it might appear at first.

The photo below shows, in clock-wise order starting from the lower left: Meinhard, Andreas (openSUSE website guy), Manuel (Quassel IRC client guy), Claudia (e.V. office), Jens-Michael (Marble hacker), Isabel (Linux-something, sorry can't decipher, and not visible on this photo), Andreas (a KDE-Win32 user), Thomas (DE-CIX), Lukas (Linux Lancers captain), Alex (of CMake fame), Dominik (of Kate fame), myself and Michael (KHotKeys). Aren't they a great bunch of people whom you'd entrust the fate of your desktop? (At least compared to making informed decisions about buying cameras which handle perspectives correctly, ahem.)

اجازه بدهید ما ملاقات در فرانكفورت به جشن

Woo-hoo, cloud computing.

(Thousands of teens start screaming.)

Enough already. What I found rather disenchanting was the lack of a tiny tool to enforce mandatory access control and usage monitoring. Furthermore, the few implementations available to mere mortals are rather technologically challenged, to put it mildly. This left me no chance but to come up with a concept of my own. The result is a PHP-based SOAP/REST proxy. Naturally, PHP doesn't make this tool fast or nice, but it allows for a quick drafting of a prototype. Eventually, an extension of das Schäfchen would seem natural since it can already be used as a reverse HTTP proxy with authentication.

There are some interesting questions arising from any such concept. For example, the ability to accept streaming service calls is highly important to keep the duration of data presence on the proxy low by pushing it to the backend as soon as it arrives. However, no such pushing should happen until the user is authenticated, which happens with protocol-specific mechanisms, unless access for that particular service has been configured to accept anonymous users. Furthermore, in case one only trusts the proxy but not the services behind it, the proxy should strip authentication information, i.e. modify the stream during its redirection. This requirement is fundamentally incompatible with the SAX API and eventually will lead to another parser model. In the meantime, however, an alternative non-streaming mode is available as well. Further insufficiencies can be found in the way PHP interacts with Apache. There is no simple way to retrieve all the original headers. Therefore, the tools contains some workarounds until it can run in standalone mode.

After some hacking, it has turned out to work fairly well at around ~500 lines of code. The first release is scheduled for the end of the month.

Heutzutage muss alles als Dienst verkauft werden. Software-as-a-Service, Monitoring-as-a-Service, Platform-as-a-Service, ja geradezu Everything-as-a-Service.

Für den ad-hoc-Zugriff auf Dienste kann man bekanntlich den Dynvoker verwenden, welcher einen generischen Client darstellt. Da Dynvoker zwischen den Anwendungen des Benutzers, wie beispielsweise einem Webbrowser, und den zu nutzenden Diensten steht, kann er auch selbst als Dienst angesehen werden. Abgeleitet von den Formaten der gesendeten Formulare definiert er eine Basismenge an Schnittstellen nach außen. Bisher sind dies eine Variante von XML-RPC, dem Übertragungsformat von XForms und Web Forms 2.0, sowie application/x-www-form-urlencoded für Web Forms 2.0 und Web Forms 1.0 alias den guten alten HTML-Formularen. Zu dieser Basismenge könnte sich noch SOAP gesellen, um einerseits die Anwendung direkt in eine SOA integrieren zu können, und andererseits eine weitere Formatalternative von XForms zu unterstützen.

Interessanterweise ergibt sich hierbei dann eine Rekursion in dem Sinne, dass man mit dem Dynvoker dann auf den Dynvoker zugreifen kann. Dabei bekommt man allerdings nur eine Liste von möglichen Operationen zu sehen, da die interne Prozesslogik fehlt. Hier sticht die Forschungsfrage heraus, inwieweit man diese Logik tatsächlich nach außen sichtbar machen kann, etwa über eine clientseitig ausgeführte, möglicherweise leichtgewichtige Prozesssprache (Variante eins), oder sich auf GUI-Generierung bei Bedarf seitens des Dienstes verlassen möchte, ähnlich wie das bei BPEL4People oder dem Ansatz von UPATMI der Fall ist. Wenn man diese Abarbeitungslogik erfassen kann, können auch autonom vom System UI-Optimierungen vorgenommen werden, etwa die Zusammenfassung von mehreren Schritten in einem UI-Fragment.

Nicht umsonst wird die Prozessintegration von GUI-Ansätzen für Dienste in unserem Architekturmodell als 5. Dimension bezeichnet, und bisher gibt es trotz vieler erfolgsversprechender Ansätze hierbei keinen wirklichen Durchbruch. Die duale Betrachtung des Dynvokers sowohl als GUI-Tool als auch als ordinärer aber vielseitiger Dienst könnte die Forschung in diesem Bereich beschleunigen.

In order to give students and other interested people some more insight at what might be the next big thing according to our optimistic opinion, this blog now features a research category.

The first entry shall be about my pet project Dynvoker. While I'm currently not able to work on it much during my work time, there are still some changes now and then. One of the most recent additions is a WADL parser contributed by Christian Liebing. Along with other modifications, the dynvoker-generic-branch transforms the application into a multilaterally generic framework. The generic dimensions encompass the service description formats, the output formats, the protocol for communication with the web service and the choice of runtime environment. A fifth, rather imaginary dimension would be the integration into complex processes.

Going generic is essential in service-oriented environments, given that on the one hand the promise of SOA is the flexible wiring and re-wiring of services, and on the other hand there is as always a plethora of protocol options available in real-world applications.

The following picture illustrates the options between output formats and submission formats alone:

Add to this that various service description formats support several submission formats, and the confusion arrives at the highest level. But do ordinary users care? No, they certainly don't, and that's why user interfaces for services need to hide this complexity. The generic approach of Dynvoker is an important step into this direction. Details will be presented at the ServiceWave 2008 conference in Madrid which also has a workshop on common goals towards UIs for services. Let's see if I will be able to attend since at the same time there's another workshop on monitoring and adaptation, my current dia em dia topic which will soon lead to another blog post.

The GGZ Gaming Zone server ggzd is able to reject weak passwords using the cracklib or omnicracklib libraries. Omnicracklib has been written from scratch and has been designed to not repeat the functionality and API restrictions that cracklib has. Up until now, this small library has just been sitting in GGZ SVN without any chance to let people pick it up and suggest improvements. Now, more information and the download is easily possible on the omnicracklib website.