[Kde-pim] Moving Entities in Akonadi

[Stephen Kelly]

Hi,

One of the pending features needed to build Akonadi applications is support 
for moving Entities between collections on the server, in resources, 
notifying other classes with the correct signals and providing Jobs to allow 
consumers of libakonadi to perform moves.

Here's a list of things that are outstanding to get this finished. I think 
it's complete, but please add to it if you think of anything else.

1) Jobs
Applications need to be able to notify the server that an Entity is to be 
moved. This can be  achieved by using setParent and a EntityUpdateJob in the 
case of Collections. Reordering also needs to be updated with 
CollectionChildOrderAttribute. All this can possibly be encapsulated in an 
EntityMoveJob.

2) Entity Ancestors
As discussed in an earlier thread and at Osnabruck, Entities will need to 
have a list of the remoteIds of their ancestors in order to handle moves 
between collections correctly and reliably.

3) Monitor Signals
The server needs to emit signals through Monitor that a move has occurred. 
There are several different cases here. If an entity is moved within the same 
resource, the resource should  be able to react to the move. If an entity is 
moved between collections in different resources, one resource must react as 
if a remove operation occurred, and the other must react as if an insert 
occurred. Application-side classes listening to the Monitor should always 
consider moves as moves. Considering a move to always be separate insert and 
remove operations would break selections and persistent indexes in models 
for example.

To account for these, the signal emitted should contain a parameter for the 
identifiers of the source and destination resources. They would most likely 
be ignored by application side classes, but resources would have something 
like:

@code

void SomeResource::entityMoved(Entity entity, Collection src, Collection 
dest, const QString &srcResource, const QString &destResource)
{
  if (this->identifier() == srcResource)
  {
    if (this->identifier() == destResource)
    {
      // Handle the move within this resource
      return;
    }
    // Handle removing entity from this resource.
  } else if (this->identifier() == destResource)
  {
    // Handle inserting entity into this resource.
  }
}

@endcode

As discussed in an earlier thread and at Osnabruck, Entities need to know a 
list of the remoteIds of their ancestors.


4) AgentBase::ObserverV2
In order for resources to be able to react to the signals, we'll probably 
need to have an ObserverV2 to add virtual methods for concrete resources to 
override. I tried to do this before with a mixin class, but it didn't work 
for a reason I don't remember. An ObserverV2 would be a better solution 
anyway, because some parameters in existing signals (eg, Collection in ### 
TODO ) will probably not be necessary when Entity knows a list of its 
ancestors.

5) Doing it in a branch?
I might have missed something regarding moves, and there may be other 
missing pieces in Akonadi API that we'll only know about as we build real 
applications on top of it. I think we need some prototype applications which 
between them use all of the features of akonadi, so we don't end up needing 
an ObserverV3 or other virtual methods in another class. I know that 
KAddressManager is around somewhere, but I don't think it handles moves for 
example. 


All the best,

Steve


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