Re: [Tracker] Can a tracker extractor change the MIME type of a input file?

["Lin, Mengdong" <mengdong lin intel com>]

Thank you, Martyn and Philip!

I think the idea of proxy is just what I need. I raised the question in another loop 
http://mail.gnome.org/archives/tracker-list/2010-December/msg00037.html
but got the answer here :-)

I'll also check whether I can integrate the DRM check in the libstreamanalyzer.

However, the license issue of tracker-extract is still pending. Because the DRM decryption libraries are 
proprietary and it's used by GStreamer decoderbin2 when extracting the meta data (Actually most DRM 
decryption libraries are proprietary). If tracker-extract is still under GPL, we cannot use GStreamer 
extractor to get the rich meta data.

Best Regards
Amanda

-----Original Message-----
From: Philip Van Hoof [mailto:spam pvanhoof be] 
Sent: Friday, December 10, 2010 7:15 AM
To: Lin, Mengdong
Cc: Martyn Russell; tracker-list gnome org
Subject: Re: [Tracker] Can a tracker extractor change the MIME type of a input file?

On Wed, 2010-12-08 at 22:07 +0800, Lin, Mengdong wrote:
> > In theory, it is possible, but I don't recommend it.
>
> > Tracker also already would register this file as an "audio" class in the 
> > ontology used and written to the database, so the mime type shouldn't 
> > need changing if you mean to search for all audio files in Tracker.
>
> How can the tracker recognize the DRM-protected content is a "audio"? 
> Do you mean it's the extractor that write the embedded media's mime type to the database?

So, I think I understand your question.

The problem is that given that the DRM container is encrypted, it cannot
reveal the MIME type of what is inside unless your DRM-enabled code
opens it. And the code that determines whether or not your DRM-enabled
code is used, uses the MIME type.

I think the best design for this is a sort of proxy pattern. You would
write an extractor that deals with the DRM part, and that extractor
passes the job on to an existing extractor.

Would something like that be possible?

So that means that your extractor registers the MIME type for DRM
content:

static TrackerExtractData extract_data[] = {
  { "application/vnd.oma.drm.content", extract_drm}
  { NULL, NULL }
};

TrackerExtractData *
tracker_extract_get_data (void) {
  return extract_data;
}

And it passes that to a native one:

static void
extract_drm (const gchar          *uri,
             TrackerSparqlBuilder *preupdate,
             TrackerSparqlBuilder *metadata)
{
  /* Get priv  - not possible atm */

  for (i = 0; i < priv->specific_extractors->len; i++) {
        const TrackerExtractData *edata;
        ModuleData *mdata;

        mdata = &g_array_index (priv->specific_extractors, ModuleData, i);
        edata = mdata->edata;

        if (g_pattern_match (mdata->pattern, length, "audio/mp3", reversed)) {
                (*edata->func) (uri, preupdate, statements);
        }
  }
}


Would something like that be doable?

Note that our extractors often use open() or fopen() on the files
themselves. We don't have a design like libstreamanalyzer has where you
can cascaded pass around a so-called stream. For example a stream that
gets decrypted by your DRM decrypter.

For something like that I think it's better if you integrate with
libstreamanalyzer and then help us integrate libstreamanalyzer into
tracker-extract. As we don't have any big plans to turn all of our
extractors into stream based ones, unfortunately.

Cheers,

Philip


-- 


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