[Nepomuk] Strigi indexer in email feeder

Sebastian Trüg trueg at kde.org
Thu Sep 29 07:41:47 UTC 2011


Normally forcing the uri should still work. The only difference is that
it will be stored as nie:url instead of being used as actual resource
URI. Did you already try it?

Cheers,
Sebastian

On 09/26/2011 11:17 PM, Christian Mollekopf wrote:
> Hey,
> 
> In the email feeder we used to be leaving some indexing tasks up to strigi,
> which was done by code like this:
> 
> KProcess proc;
> proc.setOutputChannelMode( KProcess::ForwardedChannels );
> proc.setProgram( KStandardDirs::findExe( "nepomukindexer" ); );
> proc << "--uri" << url.url().toLocal8Bit();
> proc << "--mtime" << QString::number( mtime.toTime_t() );
> proc.start();
> if ( proc.waitForStarted() ) {
>   proc.write( data );
>   proc.waitForBytesWritten();
>   proc.closeWriteChannel();
> }
> proc.waitForFinished();
> 
> Now that I switched to the dms, I don't think forcing the uri works any 
> longer.
> 
> One usecase for this is the indexing of attachments. Right now I'm only 
> creating a Nepomuk::NCAL::Attachment, but don't know how to index the data 
> with strigi. The attachment is just a QByteArray of data, so not a regular file 
> in the filesystem. There is ncal:attachmentContent, but I don't know if that 
> would result in the same.
> The old version just forced an uri in the style of 
> "akonadi:?item=123#attachmentName", when indexing the QByteArray with strigi.
> 
> 
> The second usecase is the indexing of non plaintext messages. Here I have 
> again the problem how to index the data (again a QByteArray) that it ends up 
> being associated with the email, of which I don't know the resource uri yet 
> because of the dms.
> Also here, the old version was to force the uri of the indexed data to be the 
> akonadi-uri of the email.
> 
> Any ideas how this could be done in a sane way?
> 
> Cheers,
> 
> Christian
> _______________________________________________
> Nepomuk mailing list
> Nepomuk at kde.org
> https://mail.kde.org/mailman/listinfo/nepomuk
> 


More information about the Nepomuk mailing list