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

[Kevin Krammer]

On Friday, 2011-04-29, Michael Schuerig wrote:
> 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.

Right.
 
> > 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.

It is _p.h because we don't want it installed, developers should not think 
about addressing collections using paths.

It is stable though, you could copy it into your project.

I think the path is like a Unix filesystem path, e.g. /Local Folders/Inbox for 
addressing a collection named "Inbox" in a top level collection named "Local 
Folders"

> > > * 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.

Hmm, but if you only want hits from a certain collections, than that 
collection is part of the conceptual query, is it not?
So IMHO it would make sense to also have it as a part of the Sparql query.

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20110430/dbaa8e54/attachment.sig>
-------------- next part --------------
_______________________________________________
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/