[Kde-pim] Re: Akonadi in a commandline tool

[Michael Schuerig]

On Friday 29 April 2011, Kevin Krammer wrote:
> On Friday, 2011-04-29, Michael Schuerig wrote:
> > I'm trying to access Akonadi in a commandline tool, however there
> > are still some crucial tasks I haven't found a way to achieve:
> > 
> > * Getting a list of the user-visible names of all (top level)
> > collections.
> 
> Akonadi::CollectionFetchJob using Collection::root() and fetch option
> FirstLevel
> 
> > * Instantiating a Collection given its user-visible name.
> 
> That's not directly possible since many collections can have the same
> name, e.g. having one Inbox folder per IMAP account.

It would be ok to make this into a two step process. First a list 
showing the user-visible names and the corresponding internal IDs. Then 
instantiating the collection for an internal ID.

> There is a private/uninstalled header for a collection path resolver
> that takes a "path" in a collection name hierachy and tries to
> resolve that to a collection ID. It has very likely some assumption
> on how such a path may look like.

In akonadi2xml I had already seen this code

#include <akonadi/private/collectionpathresolver_p.h>
...
  if ( args->isSet( "collection" ) ) {
    const QString path = args->getOption( "collection" );
    CollectionPathResolver resolver( path );
    if ( !resolver.exec() ) {
...

The header being clearly marked as private doesn't inspire confidence 
that I ought to use it in an Akonadi client. My interpretation was that 
it is reserved for the implementation of Akonadi itself. Anyway, I 
looked around widely in the docs and was unable to determine what a 
"path" in this context might be. Thus I was unable to make akonadi2xml 
do anything.


> > * Restricting a SPARQL query to a single collection.
> > * Providing useful error messages for malformed SPARQL queries.
> 
> No idea about search, though my guess is that collection ID/URL could
> be used as a query item, thus restricting the results to items from
> that collection. My guess is that KMail2 would be doing something
> like this when searching for messages in a particular folder (tree).

If I understand you correctly, that would entail munging the query 
string in order to add another condition. I'd rather treat the query as 
opaque and just pass it through to Nepomuk.

The context in KMail2 is different. I think I've found the relevant code 
in mailcommon/searchpattern.cpp. There a complete query is constructed 
from predetermined parts. In contrast, I'd like to support arbitrary 
queries, just restricted to a specific collection.

Michael

-- 
Michael Schuerig
mailto:michael at schuerig.de
http://www.schuerig.de/michael/
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/