Re: [Tracker] Request for review, API allowing external software like MTP daemons to get metadata as correct sparql insert

[Julie Trias <jtrias wikimedia org>]

Hello Everyone,

I am overwhelmed with the amount of response I am getting from all of you. Tracker has been haunting me for a while as it is the only other plugin I need for Gnome-do that doesn't quite work. The only missing piece of the puzzle that will satisfy my Executive Director's all-in-one search needs. If there is anything I can do outside of programming just let me know.

Kind Regards,

Julie Trias

Office IT

Wikimedia Foundation

On Tue, Jan 8, 2013 at 4:16 AM, Philip Van Hoof <philip codeminded be> wrote:

On Tue, 2013-01-08 at 12:02 +0000, Martyn Russell wrote:
> On 08/01/13 11:56, Philip Van Hoof wrote:
> > On Tue, 2013-01-08 at 11:40 +0000, Martyn Russell wrote:

> >> Not really. If that insert fails, then you're not guaranteeing the
> >> parent is inserted, which we do at the moment.
> >
> > Why would the insert fail other than something being a bug that must be
> > fixed?
>
> In the past, inserts have failed because the extracted metadata is not
> in line with the ontology of the day OR because the database is fscked.

Both are bugs that must be fixed.

> So it's usually a corner case anyway. Sometimes it's a limitation or
> restraint we have in the DB, like unique nie:url cases - but that's more
> about the code being wrong than something we can't control.

Also a bug that must be fixed.

> > And with this miner-fs isn't involved. The MTP daemon has better control
> > than inotify over the file-transfer to know when to update and when not
> > to update.
>
> Sure. Though Nokia IIRC wanted updates to things like nfo:fileSize and
> done so we didn't spam too much but had updates every n seconds, etc.

Voila, perfect solution imo. Use-case based there's no reason to have
millisecond accuracy for nfo:fileSize while a download is happening.

Unless the person who is requesting this use-case is stupid for
expecting the Nepomuk storage to provide this information. Instead this
person should see such information as application state and get the
information at the source (fstat or inotify) rather than at the
abstraction (Nepomuk).

imho Nepomuk stores aren't supposed to be real time :), but some
information can be inserted ahead of time (in case of MTP daemon
support).

> > BTW. the '20% completed' does not belong in Nepomuk and needs to be
> > communicated differently (it's application state information).
>
> Yea, I thought it might.

Kind regards,

Philip

--
Philip Van Hoof
Software developer
Codeminded BVBA - http://codeminded.be

_______________________________________________
tracker-list mailing list
tracker-list gnome org
https://mail.gnome.org/mailman/listinfo/tracker-list