kuarepoti-dju - the josef multilingual blogosphere

Being someone who often only finds time for hacking when being offline somewhere, I’ve needed a simple tool to report to myself which projects I’ve been working on the day (or night) before, so I can finish the work and eventually commit. The script now came to life under the name hackstatus.

That and other scripts are maintained in a private repository (which humourously isn’t included in the list above, as only public repos are), and I’ve now put them together and uploaded them in case anyone likes them. Just click on the image. The big set of modified files above introduces internationalised strings for carrying translations for multiple languages at once around in a server application. The data structure is called ggz_intlstring and in KNewStuff2 there’s a similar one, a class named KTranslatable. I’ve often had the need for having several translations in one string, and I wonder why there are no standard classes and structures for this, and, on a related note, no standard procedure of handling this in XML (where xml:lang exists but isn’t fully used as it could be, e.g. for multi-language text). One certainly doesn’t want to reparse configuration files just because a language is changing.

GGZ is to games what the free desktops are to applications: an environment they run in, providing a certain set of services you can rely on, and a few default games/apps shipped by default, even though the real value is in being used by 3rd party authors.

With the GGZ player communities growing, one needs better tools to ensure that everything runs smooth. There are a lot of social issues, like sometimes nasty players joining, that simply cannot be avoided by any technical tools - rather, the community itself should be empowered to solve the issues among themselves. A lot of web sites became highly popular among developers not because of the content of their web pages, but because their infrastructure can be leveraged by developers who write 3rd party tools. The GGZ Community infrastructure is now being made available via a REST-style Web Service interface as well. The design of each resource is carefully considered to match both the internal data management and the expectations of developers from the outside. It will also help separating our community web portal from the database, if we decide to use it for this application.

To give an example, player objects can be added by anyone (POST). The public data of the players can be retrieved by anyone (GET). However, when trying to modify the object (PUT or DELETE), HTTP authentication kicks in and requires the current username and password of the player object.
Add team management, statistics and all that, and one can easily integrate game reports into webpages.

What is really unfortunate about the whole issue is that the players themselves will not understand anything of what I wrote above, and think I’m wasting my time instead of adding more flashy games. But we’re not just here for all the buzz, we’re here to provide a free environment for game development, and there’s no single gaming platform on this planet as open and accessible as ours. It’s a pity that some game developers still haven’t heard the bell ringing :-)

Thanks to doxygen, the class structure below presents nicely how workflows will work in KNewStuff2. The red classes represent
the dialogs for upload and download, which are known already. The yellow classes represent the class hierarchy of the new engine,
which will transparently handle DXS if available from the provider. Right now, only the KDE-Edu repository is available via DXS
in an experimental fashion. A lot more should be during the next weeks, when we port the applications. Nevertheless, KNewStuff2
will of course work with older repositories. This is what one calls Application Wire Interface compatibility :)
Finally, the green classes represent entities which are supposed to be used by applications, mostly in a read-only fashion. Headers for
the other classes will be installed, but should not be used unless new workflows, dialogs and so on need to be implemented. The idea
of a GHNS-enabled KIO slave was raised many times, this might be such a project.

KNewStuff will (have to) be moved to kdelibs today. Things will break, help porting if you want, mostly by telling how your application
picks up the data.

Update: I forgot to mention that LWN carries a story about KNewStuff2 development.