<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 26, 2013 at 6:19 PM, Volker Krause <span dir="ltr"><<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">There are some general reasons for the extra server process:<br></div></div>
- abstracting the database backend, hardly any of them are actually compatible<br>
on the SQL level, and if they are you still might want specific optimizations.<br></blockquote><div><br></div><div>Couldn't this be done in a library?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

- generating change notifications (mainly relevant for write operations)<br></blockquote><div><br></div><div>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.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
- allow backward compatibility when changing/optimizing the db structure<br></blockquote><div><br>Again library?<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

For Akonadi there's an additional reason:<br>
- not everything you read is actually in the database, or even locally<br>
available yet.<br></blockquote><div><br></div><div>Ah. This makes sense!<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Yes, there is an overhead for this design, but 6-8x is excessive. I can't give<br>
you a general number for Akonadi, since this has been rarely the bottleneck so<br>
far. IIRC it's <20% on FETCH, and mostly due to the use of a toolkit-neutral<br>
text-based protocol (avoiding string conversions with a binary Qt-specific<br>
protocol should help).<br></blockquote><div><br></div><div>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.<br>
<br></div><div>The second is that we operate largely on QUrls and serializing/deserializing QUrls is not particularly cheap.<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
regards,<br>
Volker<br>_______________________________________________<br>
Nepomuk mailing list<br>
<a href="mailto:Nepomuk@kde.org">Nepomuk@kde.org</a><br>
<a href="https://mail.kde.org/mailman/listinfo/nepomuk" target="_blank">https://mail.kde.org/mailman/listinfo/nepomuk</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br><span style="color:rgb(192,192,192)">Vishesh Handa</span><br>
</div></div>