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

[Volker Krause]

On Sunday 26 May 2013 23:27:26 Vishesh Handa wrote:
> 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?

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
> > Nepomuk at kde.org
> > https://mail.kde.org/mailman/listinfo/nepomuk