Nepomuk as hard dependency in future?

[Sebastian Trueg]

The Virtuoso backend looks really good. It seems that with Virtuso
5.0.12 all major problems are solved and we are good to go.
However, since this all happened in the last two weeks I would like to
do more testing.
Also I could use some testers that do weirder stuff than me. After all
the developer is the worst tester. ;)
So please go ahead and give it a try. Also remember to pipe the output
of nepomukserver into a file so we can debug better.

More official stuff on Monday.

Cheers,
Sebastian

George Kiagiadakis wrote:
> On Sat, Oct 17, 2009 at 1:19 PM, Peter Penz <peter.penz at gmx.at> wrote:
>> Hi,
>>
>> currently Nepomuk is an optional dependency. There are widgets that have
>> extended functionality by using Nepomuk, but also can live without Nepomuk (e.
>> g. Dolphin has a MetaDataWidget - without Nepomuk just less meta data are
>> shown).
>>
>> One problem is that this requires a lot of #ifdef HAVE_NEPOMUK code. While
>> this is just a nasty detail in the implementation, it gets to a real problem
>> especially in header files for kdelibs, that use a Nepomuk interface like
>> this:
>>
>> class MetaDataWidget : ...
>> {
>>    ...
>>    public:
>>        QList<Nepomuk::Tag> tags() const;
>> };
>>
>> Using #ifdef HAVE_NEPOMUK code is no option as this would be BIC. If Nepomuk
>> would be a hard dependency (but for sure can be turned off during runtime as
>> always), this problem would be a no-brainer (-> tags() would just return an
>> empty list if Nepomuk is turned off).
> 
> I don't see why this is not an option. Of course it would be BIC, but
> that is what we have now as well. If you build for example dolphin
> with nepomuk support and try to link it to a kdelibs version that
> doesn't have nepomuk, it will fail. In addition, look at Qt. They are
> doing the same thing with qfeatures.h. They allow you to #ifdef out
> parts of Qt that you don't need and build a custom minimal version
> that only includes what you need. Of course, if you use this
> mechanism, the resulting libraries are BIC with any other Qt version
> out there, but that's not a reason not to have this mechanism
> available.
> 
> In general I'm not in favor of hard dependencies, but ok, if you want
> to make nepomuk a hard dependency at some point in the future, no
> problem by me, but please do it only after we have a usable soprano
> backend. Rumors say that virtuoso is going pretty well, so If virtuoso
> is ready for release with kde 4.4, then maybe it is possible to make
> nepomuk a hard dependency for 4.4... ;)
> 
> Regards,
> George
>