On Thu, 2011-02-17 at 18:37 +, David Woodhouse wrote:
I was told today that the GIO (and libsoup) async methods may not be
called from a thread other than the one running the mainloop. I found a
stupid race in libsoup¹ and filed a fix, but the bug was closed INVALID
because apparently it's
On Sun, 2011-03-13 at 21:32 +, David Woodhouse wrote:
Ug, and now I've found that that workaround doesn't work either. If we
try to rename a folder, we end up blocking in the main thread, waiting
for the soup request that we deliberately put into an idle function so
that it could run in
On Thu, 2011-02-17 at 18:37 +, David Woodhouse wrote:
I assume that your intention is that the Camel async methods would *not*
be similarly broken, and that you should be able to call them from *any*
thread and expect them not to break?
If so, we need be *very* careful about calling into
On Mon, 2010-09-27 at 12:52 -0400, Matthew Barnes wrote:
Transient operations are now implicit: if you push a new status
message onto a non-empty message stack, the message is treated as
transient. A transient message just means there's a longer delay
before the message is shown in
Here's another update on how the Camel API upgrades are coming along.
My initial roadmap from 2009 is referenced in [1], and my last update
was in May [2].
This next round of API changes will be fairly disruptive, so I'd like to
coordinate with anyone finishing up their own Camel branch so my
Hi Matthew,
On Fri, 2009-11-27 at 11:58 -0500, Matthew Barnes wrote:
In fact the mail-to-eds effort is part of what's motivating all this.
Ah ! - ok :-) sounds good.
To make the discussion more concrete, these are my current plans for
Camel's extreme makeover. The final API will
On Thu, 2009-11-26 at 14:24 +, Michael Meeks wrote:
So - I'm well up for hiding complexity behind an asynchronous API in
general; that's a great goal. I guess there is also the mail-to-e-d-s
red herring to consider in the mix - that (potentially) adds a layer
of asynchronicity to the
On Sat, 2009-11-21 at 14:57 +0530, Sankar P wrote:
On Sat, Nov 21, 2009 at 12:51 AM, Jeffrey Stedfast f...@novell.com
wrote:
Matthew Barnes wrote:
With work on Bonobo removal wrapping up, I've finally started
taking a
closer look at Camel (Evolution's mail storage and networking
library)
On Sat, Nov 21, 2009 at 12:51 AM, Jeffrey Stedfast f...@novell.com wrote:
Matthew Barnes wrote:
With work on Bonobo removal wrapping up, I've finally started taking a
closer look at Camel (Evolution's mail storage and networking library)
and laying out plans for where I'd like it to go over
Hi Matthew,
On Wed, 2009-11-18 at 14:07 -0500, Matthew Barnes wrote:
With work on Bonobo removal wrapping up, I've finally started taking a
closer look at Camel (Evolution's mail storage and networking library)
Ah - another life-time of cleaning up, and polishing code: the goal
sounds
On Fri, 2009-11-20 at 10:36 +, Michael Meeks wrote:
Hmm; you really propose to remove all threading from camel's
implementation ? or just from it's API ? a full removal might be
problematic.
There may be isolated cases internally to Camel where it can exploit
parallelism in
On Fri, 2009-11-20 at 14:21 -0500, Jeffrey Stedfast wrote:
The sqlite backend stuff could also use some work. As far as I'm
aware, the tables are non-optimal.
I really think it would be worthwhile engaging someone who has SQL
guru on their resume and asking them for help on this. Maybe just an
12 matches
Mail list logo
