On Sunday 26 May 2013 23:27:26 Vishesh Handa wrote: > On Sun, May 26, 2013 at 6:19 PM, Volker Krause <[email protected]> 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?
Backward compatibility is tricky in all directions with just a library. Your library has to be equal or newer than the db layout, older clients will lose the ability to talk to a newer server. If that's an acceptable restriction you can cover this with a library I think, the protocol compatibility guarantees for Akonadi are stricter though, and would not allow this (which only really makes sense if you consider more than one client library implementation). regards, Volker > > 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 > > [email protected] > > https://mail.kde.org/mailman/listinfo/nepomuk _______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
