Re: [Evolution-hackers] New 'eclient' branch in eds

[Matthew Barnes <mbarnes redhat com>]

On Tue, 2011-04-19 at 16:03 +0200, Milan Crha wrote: 
> No, not at all, EClient calls descendant's get_capabilities_sync on its
> own, when it's needed. The public get_capabilities API on descendants is
> sort of redundant in this case.

It that case we should have:

void     e_client_get_capabilities (EClient *client,
                                    GCancellable *cancellable,
                                    GAsyncReadyCallback callback,
                                    gpointer user_data);

gboolean e_client_get_capabilities_finish (EClient *client,
                                           GAsyncResult *result,
                                           GList **capabilities,
                                           GError **error);

gboolean e_client_get_capabilities_sync (EClient *client,
                                         GCancellable *cancellable,
                                         GList **capabilities,
                                         GError **error);

and kill the public functions in the subclasses.


> I never understood a need for this, neither used it when changing
> structs. There was done a soname version bump when changing public
> "class" structures, which, from my point of view, always involves also
> API changes, and freezes on these both are tight together. If you add a
> new member to the struct and not change the "reserved" array size (by
> how many, by the way), then you end up with a crash/critical warning
> about different structure size anyway. Doing change-and-try loops here
> sounds rather silly, from my point of view.

The need for this is to add methods to the class structure without
breaking ABI and thus avoiding a soname bump.

You can go from:

   struct _ECalClient {
       ...
       gpointer reserved[16];
   };

to:

   struct _ECalClient {
       ...
       void some_new_method (ECalClient *client, ...);

       gpointer reserved[15];
   };

and avoid forcing apps to be rebuilt.


> As icaltimezone is the main timezone for calendar in
> evolution-data-server, and will be as long as libical will be used
> there, then what about having e_cal_client_set_default_gtimezone as a
> possible alternative for e_cal_client_set_default_timezone? On the other
> hand, wouldn't e-cal-time-util.h/.c fit better here?

The fact that we use libical is an implementation detail and the fact
its data types are exposed in the public API is a shame, but we can't do
anything about that right now.

GTimezone is GNOME's official timezone API now, so that should be
reflected in our API.  Passing icaltimezones in the public API should be
secondary to passing GTimezone once we're able to support both, and I
would even be in favor of eventually deprecating APIs that pass
icaltimezone.