[Kde-pim] Still having trouble creating akonadi resource

[Ingo Klöcker]

On Sunday 04 January 2009, Stephen Kelly wrote:
> 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

This is not maildir anymore. Also it is very inefficient, at least, 
compared to what some maildir-based IMAP servers do. They map the mail 
folder hierarchy to a flat filesystem hierarchy by storing the 
hierarchy in the filesystem folder names, i.e.
drafts
inbox
inbox.subfolder1
inbox.subfolder2
kde
kde.akonadi
kde.kdepim
kde.kdepim.kmail
sent
[...]

Obviously, renaming a mail folder requires renaming all filesystem 
folders corresponding to a subfolder of the renamed mail folder. So 
renaming is expensive. But renaming a folder is not a very common task. 
The advantage of this flat hierarchy is that one gets the entire folder 
hierarchy with a single listing of a directory which is magnitudes 
faster than traversing through a complex directory hierarchy.

Note that the above filesystem folder names correspond (more or less) 
directly to the "remoteid" we already use for the maildir resource.

So a flat hierarchy on the filesystem level is a good thing. But reading 
a metadata file for all folders in order to reconstruct the folder 
hierarchy is unnecessarily slow.


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

I disagree. Top level, yes. Use metadata, no. The backend has to be 
optimized for the most common tasks. Renaming folders and moving 
folders are no common tasks.


Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090104/2a3b4714/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/