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

2011-05-10 Thread Milan Crha
On Mon, 2011-05-09 at 17:00 +0200, Milan Crha wrote:
 On Wed, 2011-05-04 at 14:37 +0200, Milan Crha wrote:
  So here left basically three things,
 a) merging some API in utils, 

Hi,
I committed a change, introducing libedataserverui/e-client-utils.h/.c

It adds new
   typedef enum {
E_CLIENT_SOURCE_TYPE_CONTACTS,
E_CLIENT_SOURCE_TYPE_EVENTS,
E_CLIENT_SOURCE_TYPE_MEMOS,
E_CLIENT_SOURCE_TYPE_TASKS
   } EClientSourceType;

(I chose this wording, in a sense: EClientSourceType tells you what is
stored behind the ESource. I harmonized this wording with
ECalClientSourceType too.)

The newly added functions are:
e_client_utils_new
e_client_utils_new_from_uri
e_client_utils_new_system
e_client_utils_new_default
e_client_utils_set_default
e_client_utils_set_default_source
e_client_utils_get_sources



The e_client_utils_open_new/_finish is still waiting its addition. Main
reason is that there is no mechanism, at the moment, to distinguish
current backend open mode/state. Right now it can be online and loaded.
It's not much documented, but from its usage I see that:
   online - TRUE, if the backend storage/server is reachable; use to be
set in 'open' backend's method or unset on failed
authentication or similar occasions
   loaded - TRUE, if the 'open' backend's method was called

What I would need is a signal from the backend, fully-opened, which
may cover authentication too. (The fully prefix is rather redundant,
but self explanatory.)

When you look how the async open method for an addressbook is written,
that located in libedataserverui/e-book-auth-util.c, then after usual
open call on the EBook it checks whether the associated ESource has
auth set, and if so, then it *forces* the authenticate_user method
call. I believe it's not correct, it may wait and respond on backend's
authentication request, but because it's not clear in what state the
backend is, with respect of opening and authenticating, then I
understand there was not many options.

This is the interstate issue Matthew mentioned earlier, in another
thread, (I understand it that way at least), where is hard to
differentiate between open-called, authenticating, fully-opened/ready
for queries.

I propose following changes in the backend:
a) add 'opening' boolean flag, which will be managed automatically. It
will be set during 'open' call, and unset only if the storage/server
will be fully connected, thus if the server will require authentication,
then the backend asks for credentials and keeps this flag to TRUE. The
flag will be automatically unset also for cases when the 'open' method
call finishes with an error. During the opening phase every call to the
backend will deny with Busy error, except of close / cancel /
authenticate_user and similar calls.
b) the backend descendants will notify client about opened either
within 'open' call itself, for cases where notification is not needed,
or when it successfully connects to the storage/server (including
authentication), by a call to function like
e_book/cal_backend_notify_opened (backend, const GError *error);
The NULL error is meant for 'success'. This will invoke signal on the
client side with a result. The internal 'opening' flag will be updated
accordingly on the e_..._backend_notify_opened() call, which is supposed
to be called every time.
c) it may not matter if the e_..._backend_notify_opened() will be called
before or after the notification about 'open' method call.
d) a new backend property opening will be introduced.
e) the loaded property might be replaced with opened and will be set
to TRUE only after the backend is successfully opened and authenticated
against its storage/server (basically on e_..._backend_notify_opened()
call with error set to NULL).
f) setting 'online' to FALSE will not result in an opened=FALSE if it
was previously opened, though the backend descendant will be able to
unset the 'opened' flag, by calling the e_..._backend_notify_opened()
with the GError set to a detailed reason why it is not opened.
g) On the client side the EClient::open-changed signal will be
introduced, which will have one argument, the GError from the
e_..._backend_notify_opened(), which will be called on each invocation
from the backend itself.

It'll be easy to do an e_client_utils_open_new() properly with above
changes done, but I would like to know opinions from others whether such
change makes sense and if you'll not see any issue with this approach.
If not, then I'll be more than happy to do this change in the EClient
branch.
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] (summarize ][) New 'eclient' branch in eds

2011-05-10 Thread Milan Crha
On Mon, 2011-05-09 at 12:04 -0400, Matthew Barnes wrote:
 On Mon, 2011-05-09 at 17:49 +0200, Milan Crha wrote: 
  It's just because of (so called) consistency. With merging common error
  codes into E_CLIENT_ERROR_ namespace I realized that checking for
  particular errors will not be that easy as is now, because one might
  have two switches, one for domain E_CLIENT_ERROR and the other for
  E_CAL/BOOK_ERROR. Not a big deal, but still.
 
 If you're using a switch statement to check for specific GErrors then
 you're doing it wrong.  You should be using g_error_matches() for each
 case, so it doesn't matter if all the error codes are in the same domain
 or they're all in different domains.
 
 I'd like to get rid of the redundancy.

OK, done on both server and client sides. Those common properties has
macro prefix CLIENT_, those specific are prefixed with BOOK_/CAL_.
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] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf

2011-05-10 Thread Patrick Ohly
On Di, 2011-05-10 at 11:40 +0100, Dumez, Christophe wrote:
 I have tested the patch but it does not seem to help. I don't know what the 
 reason is yet.

If you have never run Evolution, there will be no gconf entries for
addressbook. The second part of the fix was to have libecal create this
entry when creating a new system address book.

-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/


___
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] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf

2011-05-10 Thread Patrick Ohly
Hello!

It seems that a similar problem exists in libebook if no address books
were created already by Evolution. Chris is seeing such an issue with
2.32.3 in MeeGo.

We probably need to add the create GConf entry for local:system part
to libebook in the gnome-2-32 branch. Is that something that is still of
interest for Trunk, given that EClient API will obsolete it for 3.2?

-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/


___
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] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf

2011-05-10 Thread Patrick Ohly
On Di, 2011-05-10 at 09:34 +0100, David Woodhouse wrote:
 On Tue, 2011-05-10 at 10:19 +0200, Patrick Ohly wrote:
  It seems that a similar problem exists in libebook if no address books
  were created already by Evolution. Chris is seeing such an issue with
  2.32.3 in MeeGo.
 
 Oh, tits. I hate the fact that all this code is so *gratuitously*
 separate.

Yeah, me too. 3.2 will be better, but will still have separate
libebook/libecal libraries.

  We probably need to add the create GConf entry for local:system part
  to libebook in the gnome-2-32 branch. Is that something that is still
  of interest for Trunk, given that EClient API will obsolete it for
  3.2?
 
 It's still relevant for now, so let's do it. We *could* make a case for
 not bothering, and just fixing it in 3.0 and 2.32 instead. But our
 policy is to backport only fixes from master, and I prefer not to set a
 counter-precedent unless I absolutely have to. It doesn't *hurt* to fix
 it in master first.
 
 Do you have a patch?

Sorry, no. And no time either :-/

-- 
Bye, Patrick Ohly
--  
patrick.o...@gmx.de
http://www.estamos.de/


___
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] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf

2011-05-10 Thread David Woodhouse
On Tue, 2011-05-10 at 11:40 +0100, Dumez, Christophe wrote:
 
 I have tested the patch but it does not seem to help. I don't know
 what the reason is yet.

It may depend on earlier fixes? Can you show your patch?

 This e-mail and any attachments may contain confidential material for
 the sole use of the intended recipient(s). Any review or distribution
 by others is strictly prohibited. If you are not the intended
 recipient, please contact the sender and delete all copies.

Please don't post to public mailing lists with this unenforceable
nonsense. If you file a ticket with the helpdesk, they will remove it
for your outbound mail. (And if they refuse, get a name and contact me
in private).

-- 
dwmw2

___
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] [PATCH 1/2] e_cal_new_system_foo() should create corresponding source in GConf

2011-05-10 Thread David Woodhouse
On Tue, 2011-05-10 at 10:19 +0200, Patrick Ohly wrote:
 It seems that a similar problem exists in libebook if no address books
 were created already by Evolution. Chris is seeing such an issue with
 2.32.3 in MeeGo.

Oh, tits. I hate the fact that all this code is so *gratuitously*
separate. Because my patch ended up calling get_local_source() three
times (for cal/tasks/memos) I was tricked into thinking I'd already
covered everything; the fact that that was all still just *calendar* and
I hadn't handled the addressbook side had temporarily eluded my feeble
mind.

 We probably need to add the create GConf entry for local:system part
 to libebook in the gnome-2-32 branch. Is that something that is still
 of interest for Trunk, given that EClient API will obsolete it for
 3.2?

It's still relevant for now, so let's do it. We *could* make a case for
not bothering, and just fixing it in 3.0 and 2.32 instead. But our
policy is to backport only fixes from master, and I prefer not to set a
counter-precedent unless I absolutely have to. It doesn't *hurt* to fix
it in master first.

Do you have a patch?

-- 
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] e_cal_remove_object_with_mod() + empty rid: semantic?

2011-05-10 Thread Milan Crha
On Wed, 2011-05-04 at 17:31 +0200, Patrick Ohly wrote:
 On Mi, 2011-05-04 at 09:41 +0200, Patrick Ohly wrote:
  On Mi, 2011-05-04 at 07:50 +0200, Milan Crha wrote:
   I would expect that with CALOBJ_MOD_THIS it may remove only exact
   component, for uid + NULL-rid the master object (which implies also all
   generated instances) and keep all detached instances,
  
  Okay, then we agree on the desired semantic.
 
 I ran into another oddity: suppose there is a recurring event without
 exceptions and a detached recurrence gets added. The libecal API does
 not support undoing that operation.
 ...

Hi,
it sounds like you might find useful an addition of a reverse function
for
gboolean e_cal_client_get_object_sync (
 ECalClient *client,
 const gchar *uid, const gchar *rid,
 icalcomponent **icalcomp,
 GCancellable *cancellable, GError **error);
which can return either one component, or a VCALENDAR component.

I'm thinking of something like:
   e_cal_client_replace_object (..., const gchar *uid,
 /* const */ icalcomponent *icalcomp, ...);
Note it doesn't take the 'rid' parameter as the get_object function.

Its meaning would be drop whatever you have stored for the component of
the given uid and use content of given icalcomp instead, which could be
either single component or a VCALENDAR with a list of detached
components. There might be some checking that the uid matches uids
stored in the icalcomp, but that's a minor thing.

Just an idea.
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