On Mon, May 27, 2013 at 11:26 PM, Volker Krause <[email protected]> wrote:
> 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). > 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.
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
