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



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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]