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

[Vishesh Handa]

On Mon, May 27, 2013 at 11:26 PM, Volker Krause <vkrause at kde.org> wrote:

> 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).
>

Ah. Makes more sense now. Akonadi was supposed to be a desktop neutral
solution.

I've pushed the changes. Now all reads happen by directly communicating
with the database.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20130528/18b14d31/attachment.html>