[Kde-pim] Still having trouble creating akonadi resource

[Stephen Kelly]

Volker Krause wrote:
>> If you then move the bat collection from 'foo' to 'bar', suddenly the
>> remoteId for item1 is wrong. It would need to be changed
>> to 'bar/bat/item1', right? I don't know if there's a sensible way to keep
>> that kind of thing up to date. It's not as much of a problem if the
>> remoteId only knows its parent, but not grandparent or greater. Still it
>> would need to be kept up to date, and that could get messy. I think the
>> best solution is for remoteIds to not have any information about their
>> parents.
> 
> This also applies to IMAP, even more so as even the item IMAP UID changes
> during a move. Updateing the remote id is mandatory anyway then.
> 
> However, renaming a parent in the hierarchy is a problem with a backend
> that uses the name as a folder identifier (eg. every filesystem based
> backend). That would require an (otherwise not needed) update of the
> remote Ids of all children. Something we need to solve for eg. the maildir
> backend as well.

Well, I don't think it ever makes sense to use the name of a collection as a
folder identifier/remoteId even for filesystem based backends. The solution
I use in the kjots resource is to treat the name as metadata and create a
random unique string for the remoteId of collections and items. Currently
in svn I have 'foo.kjbook' etc, but that's just to keep things easy and
recognizable while developing.

Here's what the maildir resource should do assuming a maildir 'rooted' at
~/Random/maildirstuff':

stephen at wopr:~/Random/maildirstuff$ tree
.
|-- metadata
|-- random1.maildir
|   |-- metadata
|   |-- random11.email
|   `-- random12.email
|-- random2.maildir
|   |-- metadata
|   |-- random21.email
|   `-- random22.email
`-- random3.maildir
    |-- metadata
    |-- random31.email
    `-- random32.email

3 directories, 10 files
stephen at wopr:~/Random/maildirstuff$ cat metadata
<name>Maildirstuff</name>
<Contents>
<Collection>random1.maildir</Collection>
<Collection>random2.maildir</Collection>
</Contents>

stephen at wopr:~/Random/maildirstuff$ cat random1.maildir/metadata
<name>Name of Collection 1</name>
<Contents>
<Email>random11.email</Email>
<Collection>random3.maildir</Collection>
<Email>random12.email</Email>
</Contents>



So, as you see all collections are in the 'top level'. The way they are
nested is in metadata, and the name is in metadata. That way, if the
resource wants to rename a collection, the remoteId doesn't change, and it
just edits the name in the metadata file. If an item or collection is
moved, remove the reference to it from one metadata file, and add it in the
other.

Collections are not nested in the filesystem, so no remoteId needs any
information about it parent (which they can't anyway as above). If you had
something like 

$ tree
.
`-- Foo
    |-- Ban
    `-- Bar
        `-- Bat
            `-- random.email

And the resource was told to move email 'random.email' from the collection
with remote id 'Bat' to 'Ban', the resource would need to know that those
collections are below 'Foo' and 'Bar'. I don't think the resource can know
that, so it makes more sense to keep them all top level and use metadata
changes to 'move' them.


> 
>> You can probably tell I'm trying to encode some best practices on how to
>> use the akonadi library.
> 
> That's a very good idea. As you can probably tell, we don't have a best
> practice for all cases yet ;-)
> 
>> >> I still would have the issue of not
>> >> knowing both the source and destination when a collection is moved.
>> >>
>> >> However, itemMoved(Item, Collection src, Collection dest);, and
>> >> collectionMoved(Col, Collection src, Collection dest); in the observer
>> >> would make this problem go away.
>> >
>> > Right, that's an oversight in the API, both should be added.

I was looking into ways to keep BC.
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++

It looks like we might have to require all resources to do that
disconnect/reconnect messing.

Another solution I think might be possible to create a mixin class with the
new virtuals, and then require that all new resources are 

class SomeResource : public Akonadi::ResourceBase,
                public Akonadi::AgentBase::Observer, 
                public Akonadi::ResourceMovingMixin
{
};

Would that work? 

regards,

Steve.

> 
> regards
> Volker


_______________________________________________
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/