Monday, October 5, 2009

On BA Chapter 12 (KDE arch)

KDE is working proof that the Open Source Bazaar style is a successful software development model that can yield great technologies comparable and often even superior to some of the most complex commercial software. Now, in its 4.0 version, KDE has learned to deal with all the demands of a modern platform: pervasive concurrency, increasingly distributed processing, easier to use, cleaner and more beautiful interfaces, meaningful responsiveness, clean interactions with the software, high reliability, stability and data safety.

The social and coordinative aspects of the context in which KDE is being developed are even more interesting. In this environment achieving good communication and getting favorable consensus are imperative; these are usually hampered by distance, cultural barriers, one’s own preferences and prejudices. For larger and successful open source projects as KDE its structure is very important, as it needs to hold trademarks, receive donations organize conferences etc. In fact, finding a formal structure, to solve problems KDE faced once it became significant and at the same time it did not hinder the further development of the project, contributed most significantly to the long-term stability of the project community.

The Akonadi framework, one of the so called pillars of the KDE platform aims to provide access to the user’s personal information, the associated metadata, and the relationships between these data, as well as the services operating on them. This information is aggregated from a variety of sources, such as email and groupware servers, web and grid services, local apps that feed into it. Additionally Akonadi caches this information and provides access to it. Most of the important design decisions of the project have been taken over a series of meetings beginning with the meeting that brought the initial fundamental idea, which was the need for a robust, reliable, transactional storage layer, clearly separated from the interface and allowing concurrent multi-client access. In its current version Akonadi-PIM offers a type independent architecture, with a simple integration interface that allows for new types to be easily added by the user. This is achieved by the so-called serializer plug-ins, which are runtime libraries capable of converting back and forth from a type into a binary representation stored in the Akonadi server. From a concurrency point of view, an application generally resides in a different address space and can open one or more connections to the server, each represented internally by a thread. The storage layers rely on a solution inspired by the maildir standard, which allows lock-free ACID access by relying on atomic rename operations on the file system.

Another core library of KDE 4 is ThreadWeaver, a job scheduling library for concurrency, with its main purpose to manage and arbitrate resource usage in multi-threaded environments. By using job sequences and job collections registered in a global application job queue, ThreadWeaver assigns worker threads to the job queue thus decoupling it from the main application thread. Also, instead of relying on the direct implementation of queuing behavior, ThreadWeaver uses queue policies: one based on dependencies between resources and another based on resource restrictions. Priorities can also be used to influence the order of execution as well. Priorities can be changed without changing the job implementation by means of Decorators.

No comments:

Post a Comment