Central Services: Architecture Overview
Some of you may have heard of this project before, a research project I started with some rapid prototyping in python called “User Data Services” now renamed to “Central Services”. The idea is that you should be able to access any kind of data from any kind of data source through well tested APIs over something useful like dbus.
This replaces the need for multiple implementations of the same data access, listing, indexing and meta data storage patterns in every user application and replaces each source with plugins. Since the prototype in python has ghastly memory usage for small collections of objects I want to move to something with better resource management and I’ve been investigating Vala and implementing strong paging and object garbage collecting for this reason.
This overview diagrams the proposed architecture for this service, taking into account what I have learned in the prototype phase. It will need some existing components to work, a very good search indexer, a meta data field manager and lots of useful data access plugins before it can become truely powerful, but I believe most of these parts already exist.
I’ll be looking into this project as time allows as it’s unfunded. Let me know if you think it’s interesting or if you have any comments (or if you think it’s rubbish).
Bonus points AND a cookie for tying this into InfoPipe[1]
“”"
An additional feature of the SSSD will be to provide a service on the system D-BUS called InfoPipe. This service will act as a central authority on extended user information such as face browser images, preferred language, etc. This will replace the existing system consisting predominately of hidden configuration files in the user’s home directory, which may not be available if the home directory has not yet been mounted by autofs.
“”"
[1] http://fedoraproject.org/wiki/Features/SSSD
I am no coder or expert bu could you just leverage tracker in some way? Create some kind of ‘central services’ indexer, get the applicable data into tracker and then it would be available to any app that makes use of the tracker dbus api.
You could if tracker was a field indexer and their dbus api provided type based objects instead of file pointers and such. The full text indexer is only one part of the system.
I dont see a use for such a service yet.
But vala is good…
I liked the concept of ‘Central Services’ before it received its new name. I believe it can be immensely useful. I just have one question regarding the use of Vala. Does the use of a Gnome tool to write the application exclude its use on KDE?
Vala isn’t gnome based, nor is gobject. Are you thinking of something else?
Of course not. Libraries can be installed anywhere, and anyway, in a typical “I’m smarter than the programmer next to me”, KDE authors will probably write their own scheme for this.
(see kwin, dcop, etc.)
Maybe I am missing something but in the intro to Vala they say:
“Vala is a new programming language that aims to bring modern programming language features to GNOME developers without imposing any additional runtime requirements and without using a different ABI compared to applications and libraries written in C.”
Later:
“Many developers want to write GNOME applications and libraries in high-level programming languages but can’t or don’t want to use C# or Java for various reasons, so they are stuck with C without syntax support for the GObject type system.”
Is Vala binded to gtk & Gnome or are they just using Gnome development as an example of what Vala can do?
It’s not “bound by”, it’s “built on” technologies developed by gnome.
That said, unless you’re creating interfaces (which are obviously in gtk+ for vala), it’s fine to be used on kde. With some programming skills, you can most likely create a qt interface for a vala program too.
Aye, while they do harp on about Gnome in their docs, this project isn’t GUI based and is dBus based. It should be possible to use on any system without gnome or any gnome libs.
What does the “hardware” piece do exactly? That seems like something that is already taken care of by HAL/udev/DeviceKit/whateveritistoday no?
It takes data sources from hardware devices and translates them into usable data for the local machine. Examples are ipods (libpod), blackberries (barry), palms and so on. The idea is not to replace detection or existing access libraries but bridge the functionality into a common api for each data set.