Permission to break feature freeze for Nepomuk and Soprano

Sebastian Trüg strueg at mandriva.com
Mon Sep 3 18:34:55 BST 2007


On Monday 03 September 2007 18:53:09 Aaron J. Seigo wrote:
> On Monday 03 September 2007, Sebastian Trüg wrote:
> > I was working heaviliy on Soprano2 [1]. It comes with a bunch of new
> > features, a much cleaner API, a server/client architecture (quite simple
> > but waaaay faster than DBus), and I intend to replace the Nepomuk
>
> i have a handful of questions, not all of which impact the mergability of
> this but more just out of interest in N2 itself.
>
> were there use cases for the dbus interface outside of nepomuk itself or
> was the use of DBus completely encapsulated within Nepomuk of uninteresting
> to the outside world? iow, will this cause a meaningful regression in
> interopability potential?

Well, originally I chose DBus because it seemed the standard choice for 
inter-process communication in KDE4. I did not know about the performance 
issues then. The middleware which uses DBus was designed along the lines of 
the Nepomuk middleware as it was agreed upon in the Nepomuk project (the big 
one, not the KDE part). Back then we wanted to make the different 
implementations interoperapable (that looks wrong...), i.e. allow the KDE 
nepomuk clients to communicate with services implemented in Java (everything 
in Nepomuk is java!). But that has been dropped. So the potential was lost 
before the change I promote here. But in the end I don't think we would have 
ever really used it. Now I think relying on existing KDE technologies makes 
way more sense.

> faster is better, but reliability is another important factor. is the
> client/server stuff completely specific to Nepomuk or did you build off of
> or on top of something that already existed elsewhere?

I did not know what to build it upon, so yes, it is written from scratch.

> is there protocol documentation that comes with the new nepomuk so that
> review of it can occur without having to dive into source code?

The protocol is not defined yet but I will do that soon. I hope to get it done 
this week.
It is very simple and consists of a bunch of QDataStream operators (well, not 
the protocol, but the implementation ;) and a set of simple commands.

Cheers,
Sebastian




More information about the kde-core-devel mailing list