[Kde-pim] Can't access attributes in serializer

[Volker Krause]

On Saturday 23 November 2013 00:33:22 David Jarvie wrote:
> On Friday 15 Nov 2013 22:34:43 Volker Krause wrote:
> > On Monday 28 October 2013 12:46:53 David Jarvie wrote:
> > > Is it possible to reliably access Item attributes in
> > > ItemSerializerPlugin
> > > classes? I've found that calling AttributeFactory::registerAttribute()
> > > in
> > > the deserialize() method, to register the Attribute class, doesn't have
> > > any effect - it seems to depend on whether the *application* has called
> > > registerAttribute() as to whether deserialize() can access the relevant
> > > Attribute class.
> > 
> > attributes need to be registered before the item is retrieved from the
> > server, deserialization happens afterwards. What should work is static
> > initialization in the library they are defined in, an example can be
> > found here:
> > kdepimlibs/akonadi/kmime/attributeregistrar.cpp (you can probably ignore
> > the static lib part). This will automatically register your attributes
> > when the corresponding library is loaded.
> 
> Unfortunately this doesn't seem to work after all. It fails in the following
> circumstances.
> 
> KOrganizer is configured to use a KAlarm calendar. The calendar has a
> KAlarmCal::EventAttribute for certain events. There is no problem until the
> calendar attribute is updated by KAlarm. At that point, the
> SerializerPluginKAlarm is loaded by KOrganizer, which causes the kalarmcal
> library to be loaded. The serializer then does not recognise the attribute
> type.
> 
> I've added a static initialisation as you suggested to register
> KAlarmCal::EventAttribute into both kalarmcal library and into the
> serialiser plugin, and debug output confirms that the registration is
> executed.
> 
> I suspect the fault occurs because the plugin (and hence the library) may
> only be loaded after the item is retrieved from the server. If this is the
> case, it looks as if it's impossible (if the attribute has to be registered
> before retrieving the item from the server) to ensure that an attribute can
> be registered in time, if the application itself doesn't use the library or
> attribute, and only the plugin uses them.

You are correct, this does not work with plug-ins loaded after the 
corresponding Akonadi::Item has been retrieved.

However, in order to retrieve an item in the first place the corresponding 
serializer plug-in is loaded. There's a (theoretic, didn't check the code) 
race there for the very first item to not have its attributes deserialized 
correctly, but anything following should be correct. Your description suggests 
the plugin is only loaded for later changes though.

Also, all this should only be relevant if a client is loading items for which 
it doesn't understand the payload (ie. not linking against the corresponding 
library) but nevertheless modifies the item (otherwise you should not hit the 
serializer code). Apart from akonadiconsole, no client should do that...

So we need a bit more details to figure this out I think, what kind of items 
are we talking about? KAlarm events or KCalCore::Incidences? What is their 
mimetype in Akonadi?

Hm, both use ical for serialization, and KAlarm's mime types inherit from 
KCalCore's, right? It could be that Akonadi is using this to implicitly 
convert KAlarm events to KCalCore ones (a feature added for KCal -> KCalCore 
migration). This would explain hitting the serializer code despite only having 
read-only access in KOrganizer. The first statement above should still apply 
though, it should load the kalarm serializer to retrieve the items initially, 
as at the time of item retrieval it's not yet known what payload type the 
client will request, so it should pick the best matching one.

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/