[Kde-pim] Still having trouble creating akonadi resource

[Stephen Kelly]

Ingo Klöcker wrote:
> 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
> [...]

Ah. Yes, actually I don't know anything about maildir and I didn't look into
it. Indeed the standards are another constraint to consider here.

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

Yes, optimize for the common tasks indeed. However, if you rename the 'kde'
folder above to 'kde4', say through a rename action on the model, here's
what I think has to happen:

The resource recieves a collectionChanged signal for the collection. At that
point the collections name is 'kde4' and its remoteid is 'kde'. 

The resource does something like 'mv kde kde4'.

Then it has to set the remoteId on the collection to kde4 and fire off a
collectionModifyJob. When it recieves a signal for this later it is
ignored.

It also has to change the remoteId of and fire off collectionmodifyjobs for
each of 'kde.akonadi' 'kde.kdepim', 'kde.kdepim.kmail'. This might be a
problem because it might have to retrieve those collections from akonadi
first. It might be an even bigger problem because if you do
col.setRemoteId('kde4.akonadi') and start the job, when the result of that
job comes back to the resource, it won't be able to find a collection at
that directory. Unless you do the 'mv kde.akonadi kde4.akonadi' before
firing off that job, and assume that the job will work.

The resource also has to update the remoteId of each item in each affected
collection, doesn't it? (kde.akonadi/email1 to kde4.akonadi/email1)

That looks like a lot of work to do even for an uncommon task. Please let me
know if I've missed something here.

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

Yes. That's an advantage for retrieveCollections at least. 

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

Does that mean collection.name and collection.remoteId are tied together?

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


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