[Nepomuk] [RFC] Avoid communicating through the Nepomuk Storage

[Vishesh Handa]

On Sun, May 26, 2013 at 6:19 PM, Volker Krause <vkrause at kde.org> wrote:

> There are some general reasons for the extra server process:
> - abstracting the database backend, hardly any of them are actually
> compatible
> on the SQL level, and if they are you still might want specific
> optimizations.
>

Couldn't this be done in a library?


> - generating change notifications (mainly relevant for write operations)
>

Yes. This I agree with. This is probably the main reason why I'm going to
continue using the nepomukstorage for writes. Though maybe we should be
using database triggers instead of our own adhoc watch system.


> - allow backward compatibility when changing/optimizing the db structure
>

Again library?


> For Akonadi there's an additional reason:
> - not everything you read is actually in the database, or even locally
> available yet.
>

Ah. This makes sense!


>
> Yes, there is an overhead for this design, but 6-8x is excessive. I can't
> give
> you a general number for Akonadi, since this has been rarely the
> bottleneck so
> far. IIRC it's <20% on FETCH, and mostly due to the use of a
> toolkit-neutral
> text-based protocol (avoiding string conversions with a binary Qt-specific
> protocol should help).
>

This is probably cause the Soprano protocol is a.) Not asynchronous -
Fetching query results means asking for each result and result in a lot of
two way communication and both the storage service and the application
waiting. I think we discussed this during the PIM Sprint.

The second is that we operate largely on QUrls and
serializing/deserializing QUrls is not particularly cheap.


> regards,
> Volker
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
>
>


-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130526/57e390c9/attachment.html>