[Nepomuk] Dolphin and NepomukCore

[Vishesh Handa]

On Mon, Oct 15, 2012 at 8:46 PM, Frank Reininghaus <frank78ac at googlemail.com
> wrote:

> Hi,
>
> 2012/10/15 Vishesh Handa:
> >
> >
> > On Mon, Oct 15, 2012 at 7:16 PM, Peter Penz <peter.penz19 at gmail.com>
> wrote:
> >>
> >> Hi Vishesh and Frank,
> >>
> >> just a few short thoughts from my side, as I wrote KFileMetaDataWidget.
> I
> >> was never really happy with the implementation of KFileMetaDataWidget,
> as it
> >> needs to deal with getting meta-data by 2 different approaches (Nepomuk,
> >> Strigi) and 3 possible settings-configurations:
> >> 1. Nepomuk off + indexing off
> >> 2. Nepomuk on + indexing off
> >> 3. Nepomuk on + indexing on
> >>
> >> (there is also an option 4 with Nepomuk disabled on compiletime, but in
> >> this case KFileMetaDataWidget does not show any content)
> >>
> >> There would be a lot of room to improve the existing code even with the
> >> need to support all configurations, but personally I'd prefer another
> >> approach: I did not have a look at the new Nepomuk2-API, but if I
> remember
> >> correctly I heard there should be an asynchronous API for getting
> metadata?
> >>
> >> If this is the case and if there is a someone brave who suggests to
> reduce
> >> the 3 options above to only 2:
> >> 1. Nepomuk on + indexing off
> >> 2. Nepomuk on + indexing on
> >> *)
> >
> >
> > I would like to do that. It would make the code a lot simpler. But then I
> > don't want to be on the receiving side of all the hate. I get enough of
> that
> > already.
>
> The hate is exactly the reason why I'm sceptical about removing the
> "Nepomuk off" option, even though I see that it would make maintenance
> easier. I'm pretty sure that:
>
> a) We will get a lot of hate.
> b) Much of this hate is going to be delivered in form of Dolphin bug
> reports.
>
> And I'm not really looking forward to that either. There are enough
> depressing reports about issues that I cannot do much about already.
>
> > Maybe we could have a runtime check to see if Nepomuk is running and
> > accordingly use the new widget / KFileMetadataWidget?
>
> The disadvantages of this approach are that we would have two widgets
> to maintain, and that it is not transparent at first sight to the user
> that enabling/disabling Nepomuk also decides whether he/she gets the
> 'old' or the 'new' widget. I see a lot of potential for confusion,
> subtle bugs, and bug reports that are unclear because we don't know
> which widget is in use.
>
> Therefore I'm wondering how much work it would be to do the runtime
> check in the new widget and let it use the new "Strigi replacement"
> code retrieve the meta data from the file if Nepomuk is disabled?
>

It would be certain amount of work. I'll have to make some kind of data
provider class which would either fetch data directly from the database, or
run the indexers. Plus, as a general rule, since the indexers are plugins
and we do not control all o them. It would make sense to run them in a
separate process.

That would yield a fairly similar architecture to the one we have right
now. Maybe slightly more complex, cause in the case when Nepomuk is enabled
we would be using a thread, otherwise a process.

I'm not too keen on doing that right now. I think I'll just code a simple
replacement which only uses Nepomuk, and then start with the indexing
information. I'm more concerned with having a good user experience when
Nepomuk is enabled.



>
> Best regards
> Frank
>



-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20121015/b202458f/attachment.html>