Digikam and Nepomuk
Locked
 
|
Hey guys
As some of you might have heard. KDE is going to be dropping support for Nepomuk with its 4.13 release. Nepomuk has had a nice rice, but it has various fundamental problems which cannot be fixed. In its place a new project has been started called Baloo which does not rely on RDF and has very specific goals. From what I understand, Digikam has recently re-enabled support for synchornizing Nepomuk tags/ratings and comments via a dedicated service which does this two way synchronization. Given that Nepomuk and Baloo do not share the same data, maybe shipping with it might not be the best idea. What do you guys think? You can read more about Baloo over here [1] PS: Please keep me CCed. -- Vishesh Handa [1] http://community.kde.org/Baloo _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
2014/1/17 Vishesh Handa <[hidden email]>:
> Hey guys > > As some of you might have heard. KDE is going to be dropping support for > Nepomuk with its 4.13 release. Seriously ??? Veaceslav Munteanu has shared a lots of time this summer to fix Nepomuk support. KDE something has sad API support in time... What's we can do to port Nepomuk to this future "Baloo" framework ? Gilles Caulier > > Nepomuk has had a nice rice, but it has various fundamental problems which > cannot be fixed. In its place a new project has been started called Baloo > which does not rely on RDF and has very specific goals. > > From what I understand, Digikam has recently re-enabled support for > synchornizing Nepomuk tags/ratings and comments via a dedicated service which > does this two way synchronization. > > Given that Nepomuk and Baloo do not share the same data, maybe shipping with > it might not be the best idea. What do you guys think? > > You can read more about Baloo over here [1] > > PS: Please keep me CCed. > > -- > Vishesh Handa > > [1] http://community.kde.org/Baloo > > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
I predicted that something was going to change... but I didn't expect
to be that much. :)) So nepomukwrap , nepomukquery and nepomukwatcher are only small files that holds almost all api calls. Must be easy to port. Yet I didn't foresee a full drop and main digikamNepomukService class that depends on NepomukService. Basically without Something as NepomukService in Baloo, this piece of code is dead. On Sat, Jan 18, 2014 at 1:06 PM, Gilles Caulier <[hidden email]> wrote: > 2014/1/17 Vishesh Handa <[hidden email]>: >> Hey guys >> >> As some of you might have heard. KDE is going to be dropping support for >> Nepomuk with its 4.13 release. > > Seriously ??? > > Veaceslav Munteanu has shared a lots of time this summer to fix > Nepomuk support. KDE something has sad API support in time... > > What's we can do to port Nepomuk to this future "Baloo" framework ? > > Gilles Caulier > >> >> Nepomuk has had a nice rice, but it has various fundamental problems which >> cannot be fixed. In its place a new project has been started called Baloo >> which does not rely on RDF and has very specific goals. >> >> From what I understand, Digikam has recently re-enabled support for >> synchornizing Nepomuk tags/ratings and comments via a dedicated service which >> does this two way synchronization. >> >> Given that Nepomuk and Baloo do not share the same data, maybe shipping with >> it might not be the best idea. What do you guys think? >> >> You can read more about Baloo over here [1] >> >> PS: Please keep me CCed. >> >> -- >> Vishesh Handa >> >> [1] http://community.kde.org/Baloo >> >> _______________________________________________ >> Digikam-devel mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-devel Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
http://community.kde.org/Baloo Not much more information here, I do thing one way tag porting from nepomuk is supported. The information is at the moment somewhat sparse, some projects have already ported some code, maybe someone could look at those. But, Veaceslav if you could interface with the baloo author it would be great, at the moment there seem to be no other way. Francesco R. On 01/18/14 14:49, Veaceslav Munteanu wrote: > I predicted that something was going to change... but I didn't expect > to be that much. :)) > > So nepomukwrap , nepomukquery and nepomukwatcher are only small files > that holds almost all api calls. Must be easy to port. Yet I didn't > foresee a full drop and main digikamNepomukService class that depends > on NepomukService. > > Basically without Something as NepomukService in Baloo, this piece of > code is dead. > > > > On Sat, Jan 18, 2014 at 1:06 PM, Gilles Caulier > <[hidden email]> wrote: >> 2014/1/17 Vishesh Handa <[hidden email]>: >>> Hey guys >>> >>> As some of you might have heard. KDE is going to be dropping support for >>> Nepomuk with its 4.13 release. >> >> Seriously ??? >> >> Veaceslav Munteanu has shared a lots of time this summer to fix >> Nepomuk support. KDE something has sad API support in time... >> >> What's we can do to port Nepomuk to this future "Baloo" framework ? >> >> Gilles Caulier >> >>> >>> Nepomuk has had a nice rice, but it has various fundamental problems which >>> cannot be fixed. In its place a new project has been started called Baloo >>> which does not rely on RDF and has very specific goals. >>> >>> From what I understand, Digikam has recently re-enabled support for >>> synchornizing Nepomuk tags/ratings and comments via a dedicated service which >>> does this two way synchronization. >>> >>> Given that Nepomuk and Baloo do not share the same data, maybe shipping with >>> it might not be the best idea. What do you guys think? >>> >>> You can read more about Baloo over here [1] >>> >>> PS: Please keep me CCed. >>> >>> -- >>> Vishesh Handa >>> >>> [1] http://community.kde.org/Baloo >>> >>> _______________________________________________ >>> Digikam-devel mailing list >>> [hidden email] >>> https://mail.kde.org/mailman/listinfo/digikam-devel > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel > _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by Vishesh Handa
"The majority of Nepomuk applications just rely on tags, ratings and comments. Baloo offers a simple asynchronous API for modifying that file metadata." These are also the use scenarios which we had. (I believe faces are not implemented?) "This metadata is now stored with the extended attributes of the file instead of storing it in a separate database." If this refers to operating system level extended attributes, I will be interested to see how size limitations and cross-platform issues may be solved. In any case, if a technology is born in academia and after years of development by different, talented people cannot be brought to performance in real code, it seems to be a wise decision to change the fundamental design while keeping the higher-level API. Marcel _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
On Sun, Jan 19, 2014 at 5:26 PM, Marcel Wiesweg <[hidden email]> wrote: --
Yup, it's using xattr. Someone raised this very quesion on kde-core-devel, but it has no answer yet afaik. In any case, if a technology is born in academia and after years of The problem was exactly that - it was /too/ academic. Plus RDF on desktop (originally a web tech) just does not work that well. Also to add a personal use case - we've been doing the contact aggregation library for about 2 years using Nepomuk and the ontologies and we were still unable to get it completely right (especially because everybody interprets the ontologies a bit differently). Now we've basically reimplemented the whole thing based on simple sqlite and akonadi in about 3 months and it works waaay better, waaay faster and the code is just waaay simpler.
Which reminds me, I should look at interfacing the face tagging with contacts again when I have some free time ^_- Cheers Martin Klapetek | KDE Developer
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
On 01/20/14 12:43, Martin Klapetek wrote:
> "This metadata is now stored with the extended attributes of the > file instead > of storing it in a separate database." > > If this refers to operating system level extended attributes, I will be > interested to see how size limitations and cross-platform issues may be > solved. > > > Yup, it's using xattr. Someone raised this very quesion on > kde-core-devel, but it has no answer yet afaik. > Let me predict this will be another _mayor_ fail (unless this change). Xattr ar NOT a reliable way to store data, they can be lost in an incredible amount of ways. By default not even rsync does copy them (-X, --xattrs preserve extended attributes) _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
On Mon, Jan 20, 2014 at 2:57 PM, [hidden email] <[hidden email]> wrote:
Please voice your concern at the k-c-d thread ("Moving Baloo forward"), someone raised it there as well. No point saying this here where no Baloo developers are lurking :)
Cheers -- Martin Klapetek | KDE Developer
_______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by Marcel Wiesweg
Marcel, and everybody else, keep Vishesh in cc, he is Baloo project
manager and he wants to follow our discussion. And yet, the biggest problem is a service to keep database and files in sync. On Sun, Jan 19, 2014 at 4:26 PM, Marcel Wiesweg <[hidden email]> wrote: > > > "The majority of Nepomuk applications just rely on tags, ratings and comments. > Baloo offers a simple asynchronous API for modifying that file metadata." > > These are also the use scenarios which we had. (I believe faces are not > implemented?) > > > "This metadata is now stored with the extended attributes of the file instead > of storing it in a separate database." > > If this refers to operating system level extended attributes, I will be > interested to see how size limitations and cross-platform issues may be > solved. > > In any case, if a technology is born in academia and after years of > development by different, talented people cannot be brought to performance in > real code, it seems to be a wise decision to change the fundamental design > while keeping the higher-level API. > > Marcel > _______________________________________________ > Digikam-devel mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-devel Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
|
|
In reply to this post by Martin Klapetek
> Please voice your concern at the k-c-d thread ("Moving Baloo forward"), > someone raised it there as well. No point saying this here where no > Baloo developers are lurking :) > done, yet it still make sense let know Digikam developers they should not invest time (yet) in something which will lose the user data silently. Developer has spoken of an additional database replacing xattrs, when it will be ready this look great. Francesco Riosa _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
«
Return to digikam-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |