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

[Milan Crha <mcrha redhat com>]

On Tue, 2011-04-19 at 09:27 -0400, Matthew Barnes wrote:
> Havoc Pennington kept having to answer this same type of thing in the
> early days of GLib/GTK+ when people would ask why the API never uses
> "const" in functions that take but don't modify a GObject and GLib data
> structure.
> 
> http://mail.gnome.org/archives/gtk-devel-list/2001-May/msg00485.html
> 
> The take away there for me has always been "const" is useless for any
> kind of struct that has a pointer member, which virtually all GObjects
> do.  The API docs are a better place to document that the argument is
> not modified.  Don't try to do it in the function prototype.

I'm not sure if it's an apologize for it, but making it /* const */ may
not hurt.

> > > * Why do we have "get_capabilities" functions in EClient, ECalClient and
> > >   EBookClient?  Are they different sets of capabilities?  And if getting
> > >   capabilities involves a D-Bus call then doesn't it need to be async
> > >   everywhere?
> > 
> > They are same capabilities. Same as ECal/EBook the EClient caches
> > capabilities once it's asked for them, and reuses them, same as is
> > responsible for its memory. The cached values are also used for
> > capability checking. These are fetched on demand, and are always
> > synchronous. For cases where this is unusable, and where the caller will
> > take care of the memory, I added also get_capabilities functions to
> > ECalClient/EBookClient, which has both sync and async versions.
> 
> Hmm, so you're saying I first have to fetch the capabilities via the
> async calls in ECalClient and EBookClient, then the result is cached in
> EClient?  I'd suggest renaming the EClient function then to something
> like e_client_get_cached_capabilities().

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.

> There's a couple other simple things I forgot to mention yesterday.
> 
> * We should add some padding to all the public class structs so we can
>   add new class methods in the future without breaking ABI.  Something
>   like this:
> 
>         struct _ECalClientClass {
>         
>             ... methods and stuff ...
>         
>                 gpointer reserved[16];
>         };

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.

> * Also, GLib 2.26 gained its own timezone API: GTimezone.
> 
>   http://developer.gnome.org/glib/unstable/glib-GTimeZone.html
> 
>   It would be good to eventually try and correlate GTimezone and
>   icaltimezone.  Other projects will be using GTimezone now since
>   it's part of the GNOME platform libraries, and will likely expect
>   to be able to use GTimezone with E-D-S libraries.
> 
>   I'd like to add least make room for this in the name space now by
>   renaming all functions that expose libicaltimezone pointers from
>   "timezone" to "icaltimezone".

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?

	Milan