Re: [Tracker] strigi 0.7 rc1

[Philip Van Hoof <spam pvanhoof be>]

On Thu, 2009-07-23 at 12:31 +0300, Evgeny Egorochkin wrote:
> On Thursday 23 July 2009 11:52:46 Philip Van Hoof wrote:

> > Does this libstreamanalyzer already take into account the latest changes
> > that we made to the Nepomuk Message Ontology, for MIME files?
> >
> > In particular the nmo:hasContent changes that we made.
>
> Not yet. I'm planning an overhaul of email analyzer. I'd really like to see 
> his discussed and finally decided on first. Maybe NMO proposal is a good 
> candidate for ticket-a-day :)

Okay, #xesam and let's discuss.

> This pre-release is intended to compile a list of issues to be fixed. If you 
> find any other, please let me know.
>
> We're sort of forced to rush 7.0 out of the door, because we really have to 
> break stuff^H^H^H^H change ontology before kde 4.3 is out. After this, minor 
> releases aren't going to be a problem. This doesn't mean I consider 7.0 to be 
> very broken. But I guess it still has some rough edges.

Okay. This is great news btw.

> > Explained here:
> > http://git.gnome.org/cgit/tracker/tree/data/ontologies/34-nmo.ontology
> > http://live.gnome.org/Tracker/Documentation/EmailSparql
> >
> > > If you encounter any problems, please let me know, so the fix can make
> > > it in 0.7 final.
> >
> > I wonder what the ideal way is to build a package just for libstreams
> > and libstreamanalyzer, out of this release candidate. I also wonder
> > whether packagers are instructed to package these libraries separately.
>
> Deb guys will break it up. Actually it's already separated AFAIK. not sure 
> about other binary distros. Might give them a hint.

Great

> For Gentoo it's going to be a sort of a problem. Gentoo guys usually prefer 
> one package per one released tar.gz with a set of use flags to compile library, 
> daemon, support for various deps etc. So it means than in gentoo tracker 
> ebuild would depend on strigi ebuild. Alternatively if you can build 
> libstreamanalyzer separately they might introduce two conflicting ebuilds for 
> strigi and libstreamanalyzer with tracker ebuild being able to use either of 
> them.

Gentoo is usually a sort of a problem ;-)

> Which approach is taken depends on tracker guys being willing to be bashed by 
> anti-kde trolls :)

I'll just put this straight, because I want these things to be very
clear:

We will ignore every anti troll. From which wind direction the troll
came doesn't matter.

We're not interested in politics, we're interested in innovation.

The streamanalyzer library is innovation. That's why we are interested
in it.

This doesn't mean that we don't want a clean dependency tree.

Technically it doesn't make sense for Tracker to depend on the entire
strigi stack, we just want streams and streamanalyzer.

> I'm putting it on my todo list to ensure that there's an option to build 
> libstreamanalyzer separately

That's a very good idea, yeah.

> P.S. just checked and it seems that if I run regular build commands in 
> streamanalyzer dir, everything builds properly and is installed.
>
> P.P.S. One more unresolved issue: libstreamanalyzer currently drags ontologies 
> along. We might want to fix this to use shared ontologies, or rather fix it to 
> not care about ontologies at all. The question is: should libstreamanalyzer 
> try and validate analyzer output(especially 3rd-party analyzer output) against 
> the ontology or should it be done at backend level?

We'd like to start a freedesktop project to host a shared package
containing the ontologies in the TriG format.

We hope that you guys at strigi and people like Sebastian TrÃg join us
on that. I will try to visit the conference in Amsterdam as I understood
Sebastian will be at that conference too?

I tried to get us to actually make this package at the desktopsummit in
Gran Canaria but apparently I failed. We did succeed in agreeing on most
of things that had to be agreed:

- TriG format
- A load order index file, also in TriG or Turtle instead of filenames
  with numbers upfront the filename
- Custom ontology install procedure should be well defined
- Shared location using XDG dir specifications
- I think we even decided that we'd use autotools for the build
  environment
- etc (I hope somebody of the group who was discussing this at the
  balcony has kept a list in his mind)

We should start this project as soon as possible to avoid that softwares
like indeed, streamanalyzer, need to drag ontologies along.

Right now we need to do this for Tracker too. We'd *very* much like to
have this as a shared package between all the Nepomuk projects.

So let's start this? What are we waiting for? #xesam and let's code!

-- 
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be 
gnome: pvanhoof at gnome dot org 
http://pvanhoof.be/blog
http://codeminded.be