> On June 7, 2011, 5:44 p.m., Sebastian Trueg wrote: > > Before I look at this in detail I wanted to propose one thing: How about we > > expose the ClassAndPropertyTree from the storage service via DBus. Then > > clients can easily check ranges, domains, and so forth without the need to > > build any internal tree. > > Then maybe at some point we might even port Nepomuk::Types to use that API > > which would also mean a performance increase. > > Vishesh Handa wrote: > I agree. It doesn't make sense to for each application to maintain their > own cache, which wouldn't get updated if the ontologies are changed. But I'm > not so sure about dbus. I'd like to do some simple tests to determine how > long a round trip takes. > > What do you think about using something like KSharedDataCache? > > Sebastian Trueg wrote: > Actually I have been thinking about that from the very start. always > wanted to do that. But IMHO we should provide both: DBus API for scripts and > such and the fast shared mem solution for KDE apps. > > Vishesh Handa wrote: > AFAIK no one is writing scripts which use Nepomuk right now. So I care > more about the shared memory solution. > > Either way, adding a dbus api is a simple task.
It is agreed then. :) - Sebastian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/101522/#review3754 ----------------------------------------------------------- On June 6, 2011, 10:50 a.m., Vishesh Handa wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/101522/ > ----------------------------------------------------------- > > (Updated June 6, 2011, 10:50 a.m.) > > > Review request for Nepomuk and Sebastian Trueg. > > > Summary > ------- > > Nepomuk::Types classes are very expensive as they load all the type > properties in one go. While this was acceptable when the WriterData was > initialized only once, with the new Strigi Service architecture, the > WriterData is initialized each time a file in indexed. It doesn't make any > sense to load all the properties each time. > > Specially since we only use the range() and literalRangeType() of > Nepomuk::Types::Property > > > Diffs > ----- > > nepomuk/services/strigi/indexer/nepomukindexwriter.cpp 71d2e54 > > Diff: http://git.reviewboard.kde.org/r/101522/diff > > > Testing > ------- > > Compared previous and current indexed data for an mp3 file. > > > Thanks, > > Vishesh > >
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
