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

[David Jarvie]

On Saturday 23 Nov 2013 12:46:51 Volker Krause wrote:
> 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.

I've looked into KOrganizer's calendar configuration on my system, and it isn't what I thought. I removed all calendars but one from KOrganizer, and the only one left is a normal KOrganizer calendar with an iCal icon beside it, and I have checked that the calendar file contains no events. There are no KAlarm calendars in KOrganizer's calendar list.

With that configuration, KOrganizer runs up fine, but as soon as KAlarm updates an event containing an EventAttribute in one of its own calendars, KOrganizer loads the KAlarm serializer plugin, which fails to load the EventAttribute. I can't see any reason why KOrganizer should be looking at the KAlarm calendar. (Note that the option to copy the event to KOrganizer which can be specified in KAlarm is not set for the event which is updated.)

I then added the KAlarm calendar to KOrganizer as one of its calendars, and now it handles the EventAttribute fine, even when KAlarm updates the event. So the problem only occurs when KOrganizer is not configured to use the KAlarm calendar!

-- 
David Jarvie.
KDE developer.
KAlarm author -- http://www.astrojar.org.uk/kalarm
_______________________________________________
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/