[Kde-pim] Re: KCalCore + Observers

[Patrick Ohly]

On Di, 2011-05-03 at 20:50 +0200, Ingo Klöcker wrote:
> On Tuesday 03 May 2011, Patrick Ohly wrote:
> > Hello!
> > 
> > KCalCore uses observers to notify library users of changes. These are
> > defined as abstract base classes with a few virtual methods:
> > 
> > class KCALCORE_EXPORT RecurrenceRule
> > {
> >   public:
> >     class RuleObserver
> >     {
> >       public:
> >         virtual ~RuleObserver();
> >         /** This method is called on each change of the recurrence
> > object */
> >         virtual void recurrenceChanged( RecurrenceRule * ) = 0;
> >     };
> > ...
> > 
> > Similar for Calendar::CalendarObserver.
> > 
> > Have you considered changing this to the signal/slot mechanism? It
> > has pros and cons, of course, I just want to get a feeling for your
> > opinions.
> > 
> > The advantage is that it'll be possible to extend the API without
> > breaking the ABI.
> 
> What API do you want to extend? That of RuleObserver? I doubt that its 
> extremely slim API is supposed to be extended.

No, CalendarObserver is a more likely candidate for extensions. I only
quoted RecurrenceRule as example because it is so short ;-}

> Moreover, it's easy to 
> write a convenience class with a richer interface implementing the 
> RuleObserver interface (probably via a private implementation of 
> recurrenceChanged() to prevent further reimplementation).

I don't see how adding a convenience class will solve the problem of ABI
changes when modifying the current API. Or do you suggest to break that
API once by adding an extension mechanism (like a general virtual method
with a enum and some fixed arguments that can be overloaded later on)?

> > It would also fit better into apps which are already using QObject.
> > 
> > The disadvantage is that the observer classes can be used in apps
> > which do not use QObject.
> > 
> > A possible compromise is this:
> >       * Switch libkcalcore to the signal/slot version of the API,
> >         removing the register/removeObserver() calls and these
> > Observer base classes. Requires adding QObject as base class of some
> > classes (ReccurenceRule).
> >       * Add a second library which offers the Observer style API,
> >         implemented by connecting the signals in libkcalcore to slots
> > in the observers. Its ABI would break if future changes are needed.
> 
> If you prefer connecting to signals instead of implementing the observer 
> interface then you could implement a QObject-derived 
> SignalingRuleObserver which works internally as observer (e.g. by 
> implementing recurrenceChanged()) and externally as signal-emitting 
> QObject (with a special connect() method which does the registration and 
> the connection of your slot).

I don't prefer one approach over the other, both have pros and cons.

I'm just looking at this as someone who'll have to maintain a stable ABI
for the resulting libraries in MeeGo. Perhaps I worry too much.

-- 
Bye, Patrick Ohly
--  
Patrick.Ohly at gmx.de
http://www.estamos.de/


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