Re: [Evolution-hackers] New 'eclient' branch in eds
On Tue, 2011-04-19 at 19:02 -0400, Matthew Barnes wrote: > On Tue, 2011-04-19 at 23:25 +0100, David Woodhouse wrote: > > Note the 'gboolean retrying' argument to the libsoup "authenticate" > > signal handler. We probably want to have something similar in the above > > API too, because that's what tells the UI that it needs to ditch the > > existing remembered password and ask for a new one. > > Excellent point, definitely want that. e_credentials_equal() or e_credentials_equal_keys() offers such functionality without a need of an extra parameter in a callback - I do that in the http calendar backend, if you want to look. Maybe it needs a little bit fixing, but such logic may work, mostly. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Tue, 2011-04-19 at 23:25 +0100, David Woodhouse wrote: > Note the 'gboolean retrying' argument to the libsoup "authenticate" > signal handler. We probably want to have something similar in the above > API too, because that's what tells the UI that it needs to ditch the > existing remembered password and ask for a new one. Excellent point, definitely want that. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Tue, 2011-04-19 at 10:40 -0400, Matthew Barnes wrote:
>
> 2) ECredentials is way too complex. My intent for ECredentials was to
>have a self-contained authentication handling interface to avoid all
>the current nonsense with ECal and EBook where you have to always
>remember to connect to authentication signals and then implement the
>keyring lookup and user password prompting yourself.
>
>I probably didn't spell this out very well initially, but what I had
>in mind was a simple abstract interface to replace "auth-required"
>signals.
>
>struct _ECredentialsInterface {
>GTypeInterface parent_interface;
>
>void(*get_password) (ECredentials *credentials,
> EClient *client,
> GCancellable *cancellable,
> GAsyncReadyCallback callback,
> gpointer user_data);
>
>gchar * (get_password_finish) (ECredentials *credentials,
> GAsyncResult *result,
> GError **error);
>};
Note the 'gboolean retrying' argument to the libsoup "authenticate"
signal handler. We probably want to have something similar in the above
API too, because that's what tells the UI that it needs to ditch the
existing remembered password and ask for a new one.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] gnome-3-0 branch broken
On Tue, 2011-04-19 at 21:00 +0200, Denis Washington wrote: > During today's round of jhbuilding I noticed that the gnome-3-0 branch > of e-d-s currently fails to build. The reason is a backport of a fix for > bug #645783 [1] which relies on the sealing of CamelService done in > master. I have attached a (hopefully correct) patch which fixes the problem. Hey, at least it looked like real C code. Take a look at the same patch backported to 2.32: http://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-2-32&id=c25eab6d This is now fixed in both 3.0 and 2.32; thanks for pointing it out. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] gnome-3-0 branch broken
Hello,
During today's round of jhbuilding I noticed that the gnome-3-0 branch
of e-d-s currently fails to build. The reason is a backport of a fix for
bug #645783 [1] which relies on the sealing of CamelService done in
master. I have attached a (hopefully correct) patch which fixes the problem.
Regards,
Denis Washington
[1]
http://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-3-0&id=0db09cf5193608cc79f04f38db9b848a0ba03fe0
diff --git a/camel/camel-service.c b/camel/camel-service.c
index b922e47..8e19cff 100644
--- a/camel/camel-service.c
+++ b/camel/camel-service.c
@@ -138,7 +138,6 @@ service_get_path (CamelService *service)
* current set of services.
*/
- gpath = g_string_new (service->provider->protocol);
if (CAMEL_PROVIDER_ALLOWS (prov, CAMEL_URL_PART_USER)) {
use_path1 = g_string_new ("");
@@ -202,7 +201,7 @@ service_get_path (CamelService *service)
use_path2 = NULL;
}
- ret_path = g_build_filename (service->priv->provider->protocol,
use_path1 ? use_path1->str : NULL, use_path2 ? use_path2->str : NULL, NULL);
+ ret_path = g_build_filename (service->provider->protocol, use_path1 ?
use_path1->str : NULL, use_path2 ? use_path2->str : NULL, NULL);
if (use_path1)
g_string_free (use_path1, TRUE);
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Tue, 2011-04-19 at 18:37 +0200, Milan Crha wrote: > Hmm, I think I understand, but I do not see clearly the point. Sometimes > you do not know if the server requires the authentication, only after > open, which will deliver (on idle) the "auth-required" signal, which can > come before the backend notified "open-done", or after, it depends. What > about offline mode? What about offline server which requires > authentication when evolution is online? (The CalDAV calendar backend > deals with that case, somehow.) Try to think about this from an application author's point of view. All the things you're describing should be handled internally to EBookClient or ECalClient without cluttering up the public API. What I'm trying to do is think about all the things about ECal and EBook that have confused me or have been a pain in the ass to deal with over the years and try and make it easier for application authors like myself. And connection management and authentication is a big pain point with the current API. Right now we store passwords in GNOME Keyring and we build our own password dialog when we need to interact with the user. But that might not always be the case. In fact there's a thread right now over on desktop-devel-list that might change all that really soon. We need an authentication API that's generic enough that it won't break as these technologies and policies change and evolve. As an application author, all I want to have to do is create some ECredentials object that that implements the current authentication policies. I don't really care what those policies are, and I don't want to have to deal with them myself. Then I can pass that ECredentials object any time I need to create a new EClient. I just call e_cal_client_new() or e_book_client_new(), pass the ECredentials object along with some ESource, wait for the callback, and I'm done. I can start making calls to the calendar or address book right away. If I'm in offline mode, then certain calls will error out. That's fine. And if for some the connection needs to re-authenticate with the server, the EClient already has my ECredentials object so it can handle everything itself. That's the experience I'm after. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Rethinking account management
There's a really interesting thread over on desktop-devel-list. David Zeuthen is taking on the task of desktop-wide online account management for GNOME 3.2, with E-D-S integration among other things. What he's describing sounds like the missing piece in my account management redesign for dealing with online services and groupware accounts. I've already said as much on the list. Everyone should read this: http://mail.gnome.org/archives/desktop-devel-list/2011-April/msg00107.html ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Tue, 2011-04-19 at 10:40 -0400, Matthew Barnes wrote: > 1) There's no need for apps to use numeric IDs to track asynchronous >operations; GCancellable fills that role. GCancellable is the app's >handle to the ongoing operation. If the app wants to cancel an >unfinished operation, it calls g_cancellable_cancel(). > >The following functions should be dropped from the public API: > > e_client_cancel_op() > e_client_register_op() > e_client_unregister_op() > >All functions that kick off an asynchronous operation should return >"void". If you need to use numeric IDs to track D-Bus operations, >do so internally. Create an "e-client-private.h" if you need to. >Don't expose it in the public API. I was afraid of an overuse of the GCancellable, as it is used for the DBus communication and then for the whole operation lifetime too. But you've right, both ways are probably not needed. > 2) ECredentials is way too complex. My intent for ECredentials was to >have a self-contained authentication handling interface to avoid all >the current nonsense with ECal and EBook where you have to always >remember to connect to authentication signals and then implement the >keyring lookup and user password prompting yourself. > > ... >The benefit here is that apps can simply pass some pre-packaged >ECredentials implementation when creating calendar or address book >connections and not have to worry about handling authentication >beyond that. > >The ECredentials API you came up with would be one possible >implementation of the raw ECredentials interface illustrated above. >It should live in libedataserverui or maybe just in Evolution so it >can run a password dialog or whatever other GTK-related things it >may need to do. Please see libedataserverui/e-client-authenticate.*. It does that. The ECredentials is also used in authenticate_user backend implementations, allowing ask for any backend (as you cannot ask for a password for an address book from a contact calendar backend right now), and one is also able to ask for a PIN, as was asked for by the kolab developers. I covered your requirements and (at least) those two above in a simpler way, at least for me. > 3) The "new" functions for EClient classes should be asynchronous, and > ... >I'd really like for establishing a D-Bus connection to the backend, >connecting to a remote server, and authenticating via ECredentials to >be *one* step for the app. It either all works and you get back a >fully connected and authenticated EClient object, or something fails >and you get back NULL with a GError set. > >I want to avoid these weird in-between states where you're holding a >client object but you haven't connected to the backend yet, or you >failed to authenticate with the remoter server, etc. It just makes >life difficult and confusing for apps trying to figure what they're >supposed to do in these cases. > ... Hmm, I think I understand, but I do not see clearly the point. Sometimes you do not know if the server requires the authentication, only after open, which will deliver (on idle) the "auth-required" signal, which can come before the backend notified "open-done", or after, it depends. What about offline mode? What about offline server which requires authentication when evolution is online? (The CalDAV calendar backend deals with that case, somehow.) I agree that invoking operations on backends which are opened but not authenticated yet leads to issues, bugzilla shows "couple" of them, but I seem to miss here something too. Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
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.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Tue, 2011-04-19 at 19:39 +0530, Chenthill Palanisamy wrote: > I would like you to a incorporate some change to the free/busy api. > Some servers allow querying free/busy information > for multiple users at a time and the results appear in a iterative > fashion. The freebusy information of some > users are delivered first, while the server keeps fetching other > user's free/busy information. So if we could have he > FreeBusy api such as this, we could leverage those features, > > ECalClientFreeBusy > e_cal_client_get_freebusy_object_sync (ECalClient *client, time_t > start, time_t end, const GSList *users, GCancellable *cancellable, > GError **error); > (with a async counter-part) > > Signal: freebusy_received (ECalClientFreeBusy *fbobject, const gchar > *user, GSList *ecalcomps) > > The clients could watch for the signal and update the freebusy > information as and when they receive from eds. Hi, one more function would be needed, to tell backend from the client that it may stop delivering free/busy information and/or focus on a new query. Otherwise you may get responses really any time, which is not what you actually want. It all seems to me like an ECalView for free/busy, rather than anything doable on the backend client itself. Remember the factory shares backends between data-book/cal-s. With views, all known are notified about changes on objects (if they belong to the view), thus even as a view this will not be that easy on the server side to do, with some hard management of who (EDataCal) is looking for what (different users, time interval...). Bye, Milan ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Mon, 2011-04-18 at 15:57 +0200, Milan Crha wrote:
> I just created a new branch 'eclient' in eds [1] where is added my work
> on the new API which will deprecate EBook/ECal. It is following glib/gio
> async pattern and, I believe, makes things more coherent.
There's a few other weightier issues in the client-side APIs that I
wanted to address separately after getting the trivial stuff out of the
way. Three topics:
1) There's no need for apps to use numeric IDs to track asynchronous
operations; GCancellable fills that role. GCancellable is the app's
handle to the ongoing operation. If the app wants to cancel an
unfinished operation, it calls g_cancellable_cancel().
The following functions should be dropped from the public API:
e_client_cancel_op()
e_client_register_op()
e_client_unregister_op()
All functions that kick off an asynchronous operation should return
"void". If you need to use numeric IDs to track D-Bus operations,
do so internally. Create an "e-client-private.h" if you need to.
Don't expose it in the public API.
2) ECredentials is way too complex. My intent for ECredentials was to
have a self-contained authentication handling interface to avoid all
the current nonsense with ECal and EBook where you have to always
remember to connect to authentication signals and then implement the
keyring lookup and user password prompting yourself.
I probably didn't spell this out very well initially, but what I had
in mind was a simple abstract interface to replace "auth-required"
signals.
struct _ECredentialsInterface {
GTypeInterface parent_interface;
void(*get_password) (ECredentials *credentials,
EClient *client,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data);
gchar * (get_password_finish) (ECredentials *credentials,
GAsyncResult *result,
GError **error);
};
Some kind of object implementing the ECredentials interface would be
passed to the EClient as a construct property. Then when EClient
gets notified by the backend that authentication is required, it
would simply call the get_password() method from an idle callback.
Whatever implements the get_password() method should then handle the
password lookup and, if necessary, user prompting, all by itself.
The benefit here is that apps can simply pass some pre-packaged
ECredentials implementation when creating calendar or address book
connections and not have to worry about handling authentication
beyond that.
The ECredentials API you came up with would be one possible
implementation of the raw ECredentials interface illustrated above.
It should live in libedataserverui or maybe just in Evolution so it
can run a password dialog or whatever other GTK-related things it
may need to do.
3) The "new" functions for EClient classes should be asynchronous, and
I'd like to drop the "open" functions:
e_client_open()
e_client_open_finish()
e_client_open_sync()
(Keeping the open() *class method* around might make sense to help
make subclassing EClient easier.)
I'd really like for establishing a D-Bus connection to the backend,
connecting to a remote server, and authenticating via ECredentials to
be *one* step for the app. It either all works and you get back a
fully connected and authenticated EClient object, or something fails
and you get back NULL with a GError set.
I want to avoid these weird in-between states where you're holding a
client object but you haven't connected to the backend yet, or you
failed to authenticate with the remoter server, etc. It just makes
life difficult and confusing for apps trying to figure what they're
supposed to do in these cases.
To that end, EClient should implement the GAsyncInitable interface
from GIO, and create instances with g_async_initable_new_async()
instead of g_object_new().
http://developer.gnome.org/gio/unstable/GAsyncInitable.html
The "new" function for ECalClient should be something like:
void e_cal_client_new (ESource *source,
ECredentials *credentials,
ECalClientSourceType source_type,
GCancellable *cancellable,
GAsyncReadyCallback callback,
gpointer user_data);
ECalClient * e_cal_client_new_finish (ESource *source,
GAsyncResult *result,
GError **error);
Similarly for EBookClient.
___
evolution-hackers mailing list
Re: [Evolution-hackers] New 'eclient' branch in eds
On Mon, Apr 18, 2011 at 10:18 PM, Matthew Barnes wrote: > On Mon, 2011-04-18 at 15:57 +0200, Milan Crha wrote: >> I just created a new branch 'eclient' in eds [1] where is added my work >> on the new API which will deprecate EBook/ECal. It is following glib/gio >> async pattern and, I believe, makes things more coherent. > > Thanks for posting this, Milan. I want to emphasize how important these > new APIs are and ask everyone to look it over and provide comments. > > I had a sneak peek at this over the weekend and jotted some notes. So > far I've only reviewed in detail the client-side headers because that's > what I'm most concerned about getting right. The rest of it can be > tweaked and changed as needed -- even the backend APIs are never truly > frozen. But the client-side APIs *will* be frozen, since that's what > other projects will be migrating to and attempting to use. > > The new client-side APIs are: > > EClient (abstract base class) > http://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-client.h?h=eclient > > ECalClient (replaces ECal) > http://git.gnome.org/browse/evolution-data-server/tree/calendar/libecal/e-cal-client.h?h=eclient I would like you to a incorporate some change to the free/busy api. Some servers allow querying free/busy information for multiple users at a time and the results appear in a iterative fashion. The freebusy information of some users are delivered first, while the server keeps fetching other user's free/busy information. So if we could have he FreeBusy api such as this, we could leverage those features, ECalClientFreeBusy e_cal_client_get_freebusy_object_sync (ECalClient *client, time_t start, time_t end, const GSList *users, GCancellable *cancellable, GError **error); (with a async counter-part) Signal: freebusy_received (ECalClientFreeBusy *fbobject, const gchar *user, GSList *ecalcomps) The clients could watch for the signal and update the freebusy information as and when they receive from eds. - Chenthill. > > EBookClient (replaces EBook) > http://git.gnome.org/browse/evolution-data-server/tree/addressbook/libebook/e-book-client.h?h=eclient > > ECredentials (authenication) > http://git.gnome.org/browse/evolution-data-server/tree/libedataserver/e-credentials.h?h=eclient > > > I'll split my comments into two posts so this doesn't get too > overwhelming. Simple, hopefully non-controversial stuff here and > meatier topics in a separate post. Overall I'm pretty happy with > the APIs. > > > * There's some overlap between the new EClient API and the new > ESource API that I'm working on. Some functions will need to be > dropped once the new ESource API is in place, so I don't know if > you want to do this now or wait. > > ESourceList is being removed so obviously any functions involving > ESourceList will be dropped: > > e_client_util_get_system_source() > e_client_util_set_default() > e_client_util_get_source_for_uri() > e_cal_client_get_sources() > e_book_client_get_sources() > > We will no longer refer ESources using URIs. We will only refer > to ESources by their unique ID string. So the following functions > will be dropped: > > e_client_get_uri() > e_cal_client_new_from_uri() > e_book_client_new_from_uri() > > Default sources will be tracked using the new ESourceRegistry API, > so the following functions will be dropped: > > e_cal_client_set_default() > e_cal_client_set_default_source() > e_book_client_set_default() > e_book_client_set_default_source() > > There's a few functions that I think are too trivial to keep in light > of the lookup capabilities of ESourceRegistry. I'd like to keep the > EClient APIs as slim as possible initially and drop these functions: > > e_cal_client_new_system() > > Instead do: > > source = e_source_registry_lookup_by_uid (registry, "system"); > client = e_cal_client_new (source, source_type, error); > > e_cal_client_new_default() > > Instead do: > > source = e_source_registry_get_default_calendar (registry); > client = e_cal_client_new (source, E_CAL_SOURCE_TYPE_EVENT, error); > > (similar functions exist for tasks and memos) > > e_book_client_new_system_addressbook() > > Instead do: > > source = e_source_registry_lookup_by_uid (registry, "system"); > client = e_book_client_new (source, error); > > e_book_client_new_default_addressbook() > > Instead do: > > source = e_source_registry_get_default_address_book (registry); > client = e_book_client_new (source, error); > > > * We should use GIO error codes whenever possible, and I see quite a bit > of overlap here. I think following error codes should be dropped: > > E_CAL_CLIENT_ERROR_SUCCESS > E_BOOK_CLIENT_ERROR_SUCCESS > > There's no need for an error code for successful operations. > > E_CAL_CLIENT_ERROR_INVALID_ARG > E_BOOK_CLIENT_ERROR_INVALID_ARG > > Use G_IO_ERROR_INVALID_ARGUMENT. > > E_CAL_CL
Re: [Evolution-hackers] New 'eclient' branch in eds
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
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] New 'eclient' branch in eds
On Tue, 2011-04-19 at 07:58 +0200, Milan Crha wrote:
> > * In EBookClient, drop the 'const' qualifier from EContact arguments.
> > Trying to use 'const' with GObjects is misguided and pointless. I've
> > cursed at EIterator many times for this.
>
> Yet another thing I wanted to address was a clear memory management
> recongnizable from function prototype. Thus if the function doesn't
> change object's/variable's content, then I made it 'const' to indicate
> it's used for reading only. Of course, inconsistencies all around the
> code in this makes it hard to do right, so the function type-casts it
> back to non-const pointer internally, because EContact API is not
> written in that way. (Though it's not only about EContact.)
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.
> > * 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().
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];
};
* 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".
For example, for now we'll have:
void e_cal_client_set_default_icaltimezone (ECalClient *client,
const icaltimezone *tz);
and eventually we can add:
void e_cal_client_set_default_timezone (ECalClient *client,
GTimezone *timezone);
which converts the GTimezone to icaltimezone internally.
___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] [Reminder] Evolution community meeting at #evolution-meet channel - April 20 - 3:30 PM UTC
Hi, The meeting goes as follows, * Project updates * Discussion on queries/decisions * Individual updates Check out http://live.gnome.org/Evolution/CommunityMeet for more details. - Chenthill. ___ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers
