The Nepomuk Situation

[Vishesh Handa]

On Mon, May 7, 2012 at 9:53 PM, Albert Astals Cid <aacid at kde.org> wrote:

> El Dilluns, 7 de maig de 2012, a les 11:48:00, Vishesh Handa va escriure:
> > On Mon, May 7, 2012 at 5:03 AM, Albert Astals Cid <aacid at kde.org> wrote:
> > > El Dijous, 3 de maig de 2012, a les 00:32:37, Vishesh Handa va
> escriure:
> > > > Hey everyone!
> > > >
> > > > snip
> > > >
> > > > The second solution is -
> > > > * nepomuk-core installs the headers in nepomuk2
> > > > * the library already has a different name, so there are no clashes
> over
> > > > there
> > > > * kde-runtime/nepomuk is removed
> > > > * nepomuk-core is added as a dependency of kde-runtime
> > > >
> > > > The problem with the second solution is that all applications using
> > >
> > > Nepomuk
> > >
> > > > will also need to depend on nepomuk-core. So far the list includes -
> > > > Dolphin, KDE-pim and Telepathy (kinda)
> > >
> > > Why is this needed? Can't they continue using the old APIs?
> >
> > Short answer: No
> >
> > Long Answer:
> >
> > The original Nepomuk APIs that are present in kdelibs are synchronous.
> They
> > basically provide a glorified cache over the Nepomuk data which is stored
> > in virtuoso. Applications which push large amounts of information into
> > Nepomuk (Feeders) do not need to know anything about the data already
> > present in Nepomuk, they just need to push large quantities of data as
> fast
> > as they can.
> >
> > Using the synchronous kdelibs APIs makes this very hard. Additionally,
> the
> > asynchronous API for pushing data provides has in-built duplicate
> detection
> > and merging. That's something that was *very hard* to implement. It seems
> > like an overkill for the clients to implement something like that on
> their
> > own.
> >
> > kde-pim and Telepathy use these new asynchronous APIs. So does Trueg's TV
> > Naming Application.
> >
> > Secondly, the APIs in kdelibs did not provide any mechanism for
> monitoring
> > changes in resources. We've now finally implemented a good method of
> > monitoring changes that does not tax the entire system. Dolphin uses this
> > new ResourceWatcher API to monitor for changes in tags and ratings.
> >
> > And finally, the new APIs provide a method for properly merging
> resources.
> > A couple of miscellaneous applications are using this - Nepomuk Tag
> manager.
> >
> > Btw, when I say "new APIs", I mean introduced in kde-runtime 4.7. So they
> > are about a year old.
>
> So you mean yes, they can, they do now and can still do it, even if using
> the
> "old" APIs are suboptimal.
>
> Right?
>

I'm sorry. What?

Yes they can still use the old apis, but it would be horribly horribly slow
and would create a lot of useless data in the process. Also somethings like
change monitoring and merging resources are flat out impossible.

I'm not okay with applications having to stick with the old faulty APIs
when we have put in so much effort to make these new ones.

Also, can we substitute the word "old apis" with "kdelibs/nepomuk apis" and
"new apis" with "datamangement apis". This is getting a little confusing.


> Albert
>
> >
> > > Cheers,
> > >
> > >  Albert
> > >
> > > > What do you guys think?
> > > >
> > > > [1] https://projects.kde.org/projects/kde/kdelibs/nepomuk-core
> > > > [2]
> > >
> > >
> http://trueg.wordpress.com/2011/06/08/nepomuk-2-0-and-the-data-management-
> > > se>
> > > > rvice/
>



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120507/03d796c2/attachment.htm>