Akonadi Results

Akonadi results of the Osnabrück 5 meeting

mysql/embedded problem no longer reproducable, backup solution with per-application network-less mysqld exists but is not implemented yet
check licensing implications of mysql
Simon promised to fix D-Bus calls from threads (which is needed to use strigi/nepomuk as well)

solved and implemented for write operations (very important for resources)
not implemented for FETCH, solution is complex: extension of the delivery queue, notification blacklists, session id vs. resource id in notification blacklists

needed for FETCH/LIST (really??), implemented expect notification loop prevention
two options: do it for all other operations as well vs. do all other operations async
a complete sync implementation would be too complex (same problems as with FETCH for every command, resource D-Bus API would be the same as the IMAP command API), consider the online case as a special case of a offline resource instead (ie. a cached resource that syncs immediately)

identify jobs via a session identifier and a job identifier
send status and error notification via D-Bus signals
has similar problems as change notifications, depends on sync/async semantics of write operations

Use a strictly increasing revision number for optimistic locking
Split data into a tree-like structure where appropriate (think IMAP BODYSTRUCTURE)
Add extra fields for special FETCH responses (think ENVELOPE)
No type-specific code in the backend required for partial data retrieval, all item parsing happens in the resource
XML or MIME based format for communication between storage and resources/agents
Store bodyparts separately in the database, the raw data optioanlly in the filesystem (requires extra work for transaction safety)

Akonadi does not search itself
we feed every data we get into strigi/nepomuk, eg. by writing stand-alone feeder apps (formerly known as search providers) or by writing/extending the corresponding strigi/nepomuk plugin
Akonadi should support self-updating virtual folders (if necessary storing the result ids), by sending the query to all involved resources and strigi/nepomuk and merging the results
updating virtual folders need still to be discussed

switch from path with user visible to unique ids for identifying collections
do not store complete path but a pointer to parent collection
will completly break the IMAP LIST command -> rename and keep the option for a IMAP-compatible LIST command

our models contain still lots of stuff which Till told us we shouldn't do, ie. use QModelIndex only for the QAbstractItemView model, solve everything else via data()

KDE dependencies are allowed for now to safe work, but avoid KDE dependencies where possible
next Akonadi meeting in Berlin in April