Re: [Evolution-hackers] Diary replaying on IMAP accounts
This is why I started looking at dropping CamelDisco* and replacing all
instances with CamelOffline* - tri-state is awful, dual-state is ftw.
anyways, if your fix works, go for it.
Jeff
On Sat, 2008-01-19 at 15:13 +0100, Philip Van Hoof wrote:
> Hi there,
>
> When we connect with an IMAP service if we have moved messages while we
> where offline, the diary's replay function will be utilised.
>
> While this takes place, the store's disco connection state is
> CAMEL_DISCO_STORE_RESYNCING.
>
> The camel_disco_store_check_online seems to only care about this state
> being ONLINE. RESYNCING is not seen as being online. It seems that
> therefore commands like the APPEND one are failing:
>
>
> void
> camel_disco_diary_replay (CamelDiscoDiary *diary, CamelException *ex)
> {
> ...
> camel_folder_append (...)
> ... or ...
> camel_folder_transfer_messages_to (...)
> ...
> }
>
>
> imap_append_online (CamelFolder *folder, CamelMimeMessage *message,
> const CamelMessageInfo *info, char **appended_uid,
> CamelException *ex)
> {
> ...
> do_append (...)
> ...
> }
>
> static CamelImapResponse *
> do_append (CamelFolder *folder, CamelMimeMessage *message,
> const CamelMessageInfo *info, char **uid,
> CamelException *ex)
> {
> ...
> response = camel_imap_command (store, NULL, ex, "APPEND %F%s%s {%d}",
> folder->full_name, flagstr ? " " : "",
> flagstr ? flagstr : "", ba->len);
> g_free (flagstr);
>
> if (!response) {
> ...
> retry ... (but eventually)
> return NULL;
> ...
> }
>
> ...
> }
>
>
> CamelImapResponse *
> imap_read_response (CamelImapStore *store, CamelException *ex)
> {
> ...
> response->untagged = g_ptr_array_new ();
> while ((type = camel_imap_command_response (store, &respbuf, ex))
> == CAMEL_IMAP_RESPONSE_UNTAGGED)
> g_ptr_array_add (response->untagged, respbuf);
>
> if (type == CAMEL_IMAP_RESPONSE_ERROR) {
> camel_imap_response_free_without_processing (store, response);
> > return NULL; <-
> }
> ...
> }
>
>
> CamelImapResponseType
> camel_imap_command_response (CamelImapStore *store, char **response,
>CamelException *ex)
> {
> CamelImapResponseType type;
> char *respbuf;
> int len = -1;
>
> if (camel_imap_store_readline (store, &respbuf, ex) < 0) {
> CAMEL_SERVICE_REC_UNLOCK (store, connect_lock);
> ---> return CAMEL_IMAP_RESPONSE_ERROR; <--- this happens
> }
>
> ...
> }
>
>
> /* FIXME: please god, when will the hurting stop? Thus function is so
>fucking broken it's not even funny. */
> ssize_t
> camel_imap_store_readline (CamelImapStore *store, char **dest, CamelException
> *ex)
> {
> CamelStreamBuffer *stream;
> char linebuf[1024] = {0};
> GByteArray *ba;
> ssize_t nread;
>
> g_return_val_if_fail (CAMEL_IS_IMAP_STORE (store), -1);
> g_return_val_if_fail (dest, -1);
>
> *dest = NULL;
>
> /* Check for connectedness. Failed (or cancelled) operations will
> * close the connection. We can't expect a read to have any
> * meaning if we reconnect, so always set an exception.
> */
>
> if (!camel_imap_store_connected (store, ex))
> ->>return -1; <---
>
> ...
> }
>
>
> gboolean
> camel_imap_store_connected (CamelImapStore *store, CamelException *ex)
> {
> ... (lot's of completely funny looking code, but eventually): ...
> camel_disco_store_check_online
> ...
> }
>
> gboolean
> camel_disco_store_check_online (CamelDiscoStore *store, CamelException *ex)
> {
> --> Nothing here seems to accept the RESYNCING state as being online
> <---
>
> if (camel_disco_store_status (store) != CAMEL_DISCO_STORE_ONLINE) {
> camel_exception_set (ex, CAMEL_EXCEPTION_SERVICE_UNAVAILABLE,
> _("You must be working online to "
>"complete this operation"));
> return FALSE;
> }
>
> return TRUE;
> }
>
>
>
> note: I have fixed this in my version by doing this:
>
>
> gboolean
> camel_disco_store_check_online (CamelDiscoStore *store, CamelException *ex)
> {
>
> if (camel_disco_store_status (store) == CAMEL_DISCO_STORE_RESYNCING)
> return TRUE;
>
> if (camel_disco_store_status (store) != CAMEL_DISCO_STORE_ONLINE) {
> camel_exception_set (ex, CAMEL_EXCEPTION_SERVICE_UNAVAILABLE,
>_("You must be working online to "
> "complete this operation"));
> return FAL
Re: [Evolution-hackers] Build failure in evo: need a lot of stuff!
On Fri, 2008-01-18 at 16:34 -0500, Jeffrey Stedfast wrote:
> On Fri, 2008-01-18 at 16:32 -0500, Paul Smith wrote:
>
> > I'm getting a build failure in Evo and gtkhtml with the latest
> glib:
>
> > editor-control-factory.c: In function 'editor_get_prop':
> > editor-control-factory.c:463: error: expected expression before 'do'
>
> > Apparently, the latest glib broke the libbonobo from Gnome 2.20, so
> if
> > you install the latest glib you also need the latest libbonobo.
>
>
>
>
> you might want to warn the glib guys about this then... seems they
> have broken API or ABI which is a strict no-no.
I'm happy to do this, but the change is not so straightforward.
The deal is this: in the old glib, g_assert() macros were surrounded by
G_STMT_START and G_STMT_END macros to make them look like single
statements even though they contain multiple statements. The statement
start/end macros back then had a little ifdef dance taken from Perl,
which used GCC special features if you built with GCC, or the old do {}
while(0) trick if that was checked for in the configure file, or if none
of that were true, the relatively obscure "if (1) ... else (void)0"
syntax.
For all Gnome builds, obviously, the GCC special capability was used.
Now, libbonobo used the g_assert() macros inside macros of their own,
that looked like this: (g_assert(...), some_other_statement()). This
is a statement that returns a value, rather than the traditional
do{}while(0) etc. methods that can only be used in a void context.
When you compiled all of this together with GCC it worked, because the
GCC macro extension used by g_assert() provides for the macro to be used
as an rvalue. If you would compile this with any compiler OTHER than
GCC, it would not work because you can't use a while loop inside a comma
expression like libbonobo is trying to do.
It's arguably a bug in libbonobo that it REQUIRES the use of GCC.
Anyway, for some reason in the newer versions of glibc the g_assert()
macro (and all its brethren) were (a) moved to a new header file
gtestutils.h, and (b) all the special Perl magic macro stuff was removed
and it uses plain do{}while(0) now. That will work the same way for all
compilers, but it breaks libbonobo's use.
The newer versions of libbonobo have changed their macros to use the GCC
syntax directly, inside their own ifdef checking for GCC. If GCC is not
set, they don't call g_assert() at all. This will now compile correctly
even on non-GCC compilers.
Soo... the old way was definitely broken: probably the real bug was
in libbonobo though. The new glib does change the API for g_assert()
_BUT_ only in such a way that shouldn't matter to any correct usage of
the macro (since any noticeable difference would have depended on using
a specific compiler).
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Exchange 2007 - MAPI Provider preview
Hi.. On Jan 18, 2008 10:21 PM, Holger Goetz <[EMAIL PROTECTED]> wrote: Is there any magic beside of > > installation, > exporting the LD_LIBRARY_PATH for samba4 > and activating the plugin, > > to get a "MAPI" or alike selection the the "Server Type" drop down? (The > plugin is there and can be activated/is activated) > The name of the plugin is 'Exchange MAPI'. The same name is used in the "Server Type" dropdown as well.. If the plugin is activated and you still can't find the server type in the dropdown - something is wrong. (start Evo in a terminal and look for a message like 'Unable to load plugin 'XYZ' - could not find shared object 'PQR.so' etc.,) > BTW: tested on 2 systems: Ubuntu 7.02, Evolution 2.12.1 and plain > debian-sid 2.12.2-1+b1 ... > Couldn't test w/ 2.21.90 from trunk of svn - as the rpm's install in > default libs and not into "/opt/evo/" or alike. > Just to make it crystal clear, you may either: + install the RPMs from the URL Johnny mentioned... + build from source from the following branches (and not SVN trunk) http://svn.gnome.org/viewvc/evolution-data-server/branches/EXCHANGE_MAPI_BRANCH http://svn.gnome.org/viewvc/evolution/branches/EXCHANGE_MAPI_BRANCH I had posted the configure options needed sometime ago here -> http://mail.gnome.org/archives/evolution-list/2008-January/msg00032.html -Suman ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
[Evolution-hackers] Diary replaying on IMAP accounts
Hi there,
When we connect with an IMAP service if we have moved messages while we
where offline, the diary's replay function will be utilised.
While this takes place, the store's disco connection state is
CAMEL_DISCO_STORE_RESYNCING.
The camel_disco_store_check_online seems to only care about this state
being ONLINE. RESYNCING is not seen as being online. It seems that
therefore commands like the APPEND one are failing:
void
camel_disco_diary_replay (CamelDiscoDiary *diary, CamelException *ex)
{
...
camel_folder_append (...)
... or ...
camel_folder_transfer_messages_to (...)
...
}
imap_append_online (CamelFolder *folder, CamelMimeMessage *message,
const CamelMessageInfo *info, char **appended_uid,
CamelException *ex)
{
...
do_append (...)
...
}
static CamelImapResponse *
do_append (CamelFolder *folder, CamelMimeMessage *message,
const CamelMessageInfo *info, char **uid,
CamelException *ex)
{
...
response = camel_imap_command (store, NULL, ex, "APPEND %F%s%s {%d}",
folder->full_name, flagstr ? " " : "",
flagstr ? flagstr : "", ba->len);
g_free (flagstr);
if (!response) {
...
retry ... (but eventually)
return NULL;
...
}
...
}
CamelImapResponse *
imap_read_response (CamelImapStore *store, CamelException *ex)
{
...
response->untagged = g_ptr_array_new ();
while ((type = camel_imap_command_response (store, &respbuf, ex))
== CAMEL_IMAP_RESPONSE_UNTAGGED)
g_ptr_array_add (response->untagged, respbuf);
if (type == CAMEL_IMAP_RESPONSE_ERROR) {
camel_imap_response_free_without_processing (store, response);
> return NULL; <-
}
...
}
CamelImapResponseType
camel_imap_command_response (CamelImapStore *store, char **response,
CamelException *ex)
{
CamelImapResponseType type;
char *respbuf;
int len = -1;
if (camel_imap_store_readline (store, &respbuf, ex) < 0) {
CAMEL_SERVICE_REC_UNLOCK (store, connect_lock);
--->return CAMEL_IMAP_RESPONSE_ERROR; <--- this happens
}
...
}
/* FIXME: please god, when will the hurting stop? Thus function is so
fucking broken it's not even funny. */
ssize_t
camel_imap_store_readline (CamelImapStore *store, char **dest, CamelException
*ex)
{
CamelStreamBuffer *stream;
char linebuf[1024] = {0};
GByteArray *ba;
ssize_t nread;
g_return_val_if_fail (CAMEL_IS_IMAP_STORE (store), -1);
g_return_val_if_fail (dest, -1);
*dest = NULL;
/* Check for connectedness. Failed (or cancelled) operations will
* close the connection. We can't expect a read to have any
* meaning if we reconnect, so always set an exception.
*/
if (!camel_imap_store_connected (store, ex))
->>return -1; <---
...
}
gboolean
camel_imap_store_connected (CamelImapStore *store, CamelException *ex)
{
... (lot's of completely funny looking code, but eventually): ...
camel_disco_store_check_online
...
}
gboolean
camel_disco_store_check_online (CamelDiscoStore *store, CamelException *ex)
{
--> Nothing here seems to accept the RESYNCING state as being online
<---
if (camel_disco_store_status (store) != CAMEL_DISCO_STORE_ONLINE) {
camel_exception_set (ex, CAMEL_EXCEPTION_SERVICE_UNAVAILABLE,
_("You must be working online to "
"complete this operation"));
return FALSE;
}
return TRUE;
}
note: I have fixed this in my version by doing this:
gboolean
camel_disco_store_check_online (CamelDiscoStore *store, CamelException *ex)
{
if (camel_disco_store_status (store) == CAMEL_DISCO_STORE_RESYNCING)
return TRUE;
if (camel_disco_store_status (store) != CAMEL_DISCO_STORE_ONLINE) {
camel_exception_set (ex, CAMEL_EXCEPTION_SERVICE_UNAVAILABLE,
_("You must be working online to "
"complete this operation"));
return FALSE;
}
return TRUE;
}
--
Philip Van Hoof, freelance software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://pvanhoof.be/blog
http://codeminded.be
___
Evolution-hackers mailing list
Evolution-hackers@gnome.org
http://mail.gnome.org/mailman/listinfo/evolution-hackers
Re: [Evolution-hackers] Build failure in evo: need a lot of stuff!
Le vendredi 18 janvier 2008 à 16:34 -0500, Jeffrey Stedfast a écrit : > On Fri, 2008-01-18 at 16:32 -0500, Paul Smith wrote: > > Hi all; > > > > I'm getting a build failure in Evo and gtkhtml with the latest glib: > > editor-control-factory.c: In function 'editor_get_prop': > > editor-control-factory.c:463: error: expected expression before 'do' > > Apparently, the latest glib broke the libbonobo from Gnome 2.20, so if > > you install the latest glib you also need the latest libbonobo. > > > you might want to warn the glib guys about this then... seems they have > broken API or ABI which is a strict no-no. libbonobo-2.20.3 changelog indicates that it is intended to fix some problems with glib-2.15, make sure you have at least that version. -- Gilles Dartiguelongue <[EMAIL PROTECTED]> signature.asc Description: Ceci est une partie de message numériquement signée ___ Evolution-hackers mailing list Evolution-hackers@gnome.org http://mail.gnome.org/mailman/listinfo/evolution-hackers
