The Nepomuk Situation

Albert Astals Cid aacid at kde.org
Mon May 7 18:27:04 BST 2012


El Dilluns, 7 de maig de 2012, a les 22:09:01, Vishesh Handa va escriure:
> 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.

There's some problem of communication here.

Let me try to explain myself better. As far as I understand:
 * Dolphin uses the "old" api at the moment and works "fine"
 * When the change you propose (adding new apis), you said the "old" api will 
still be there for people to use
 * The question is: "If dolphin is not changed to use the "new" api and still 
uses the "old" api will it still work as it works now or will be worse?"

Hope i'm clearer now.

Cheers,
  Albert


> 
> > 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/




More information about the kde-core-devel mailing list