[Nepomuk] Dolphin and NepomukCore

[Frank Reininghaus]

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?

Best regards
Frank