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:[email protected]] Sent: Friday, December 10, 2010 7:15 AM To: Lin, Mengdong Cc: Martyn Russell; [email protected] 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 _______________________________________________ tracker-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/tracker-list
