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 i
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 i
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
On Mon, 2010-09-27 at 12:52 -0400, Matthew Barnes wrote:
> 3. Asynchronous Methods
> ---
>
> All the upgrades I've been making to Camel over the past year, and all
> the changes described above were in preparation for this: Camel now has
> an asynchronous public API.
>
> Let m
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 Evoluti
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 chan
I wanted to give a status update on how this is progressing, since some
of you may have noticed me breaking Camel's API with gleeful abandon
since the 2.31 development cycle began.
My initial roadmap is here:
http://mail.gnome.org/archives/evolution-hackers/2009-November/msg00019.html
What's Acc
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 h
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
Hi Matthew,
On Fri, 2009-11-20 at 10:46 -0500, Matthew Barnes wrote:
> There may be isolated cases internally to Camel where it can exploit
> parallelism in CPU-intensive tasks with threading or where threads are
> necessary for interacting with synchronous-only libraries, but it should
> be used
On Sat, 2009-11-21 at 14:57 +0530, Sankar P wrote:
> On Sat, Nov 21, 2009 at 12:51 AM, Jeffrey Stedfast
> 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 Fri, 2009-11-20 at 14:21 -0500, Jeffrey Stedfast wrote:
> I agree with Michael Meeks' concerns here. I also think there are much
> more important fish to fry which are also far easier to tackle.
Sure. I should have been clearer that this is by no means a high
priority task. It will happen gra
On Sat, Nov 21, 2009 at 12:51 AM, Jeffrey Stedfast 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 the short a
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
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 the short and long
> term, with the ultimate goal of splitting it off as a
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 CPU-int
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
17 matches
Mail list logo
