Nepomuk as hard dependency in future?

[Evgeny Egorochkin]

В сообщении от Суббота 17 октября 2009 21:35:06 автор 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.

Just a clarification:
You run "nepomukserver 2>nslog" to have stderr logged to a file and then do 
"tail -f nslog" to see the log contents as they are added in real time to spor 
error messages or whatever else is of interest. Soprano is very verbose and it 
really helps to see what's going on.


> 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... ;)