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 _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
