<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, May 27, 2013 at 11:26 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="im">On Sunday 26 May 2013 23:27:26 Vishesh Handa wrote:<br>
> On Sun, May 26, 2013 at 6:19 PM, Volker Krause <<a href="mailto:vkrause@kde.org">vkrause@kde.org</a>> wrote:<br>
> > There are some general reasons for the extra server process:<br>
> > - abstracting the database backend, hardly any of them are actually<br>
> > compatible<br>
> > on the SQL level, and if they are you still might want specific<br>
> > optimizations.<br>
><br>
> Couldn't this be done in a library?<br>
><br>
> > - generating change notifications (mainly relevant for write operations)<br>
><br>
> Yes. This I agree with. This is probably the main reason why I'm going to<br>
> continue using the nepomukstorage for writes. Though maybe we should be<br>
> using database triggers instead of our own adhoc watch system.<br>
><br>
> > - allow backward compatibility when changing/optimizing the db structure<br>
><br>
> Again library?<br>
<br>
</div>Backward compatibility is tricky in all directions with just a library. Your<br>
library has to be equal or newer than the db layout, older clients will lose<br>
the ability to talk to a newer server. If that's an acceptable restriction you<br>
can cover this with a library I think, the protocol compatibility guarantees<br>
for Akonadi are stricter though, and would not allow this (which only really<br>
makes sense if you consider more than one client library implementation).<br></blockquote><div><br></div><div>Ah. Makes more sense now. Akonadi was supposed to be a desktop neutral solution.<br><br></div><div>I've pushed the changes. Now all reads happen by directly communicating with the database.<br>

</div></div></div></div>