[Evolution-hackers] Re: camel-private.h not installed
- From: Not Zed <notzed ximian com>
- To: Jules Colding <colding omesc com>
- Cc: Evolution Hackers <evolution-hackers gnome org>
- Subject: [Evolution-hackers] Re: camel-private.h not installed
- Date: Wed, 31 Aug 2005 18:07:09 +0800
Right, well, the url never really ever changes - if it does a new store
object will be created anyway, so I don't think that should be a major
issue.
On Wed, 2005-08-31 at 09:52 +0200, Jules Colding wrote:
> On Wed, 2005-08-31 at 13:58 +0800, Not Zed wrote:
> > > which is awkward, to say the least, and not really an option for
> > > distributed code.
> >
> > Well you don't need to do that anyway, you could path it in a -I thing.
>
> Sure, much better.
>
> > > Access to a locking mechanism for externally developed components is
> > > really necessary unless they should use homegrown solutions, which is
> > > not an option either I guess.
> >
> > Hmm, i'm not sure - it might depend on the particular lock. It is
> > probably possible to get away with not using any of those locks but just
> > defining your own. That's how camel-imap-* used to work, but because of
> > other problems (mainly complexity and races due to the the 4 levels of
> > interested parties, service, store, disco-store and imap-store), that
> > particular implementation was changed.
>
> Hmm... OK.
>
> I was of the impression that those particular locks in "camel-private.h"
> was of mandated use due to design issues up-source, since everybody
> seemed to use them. Well, I'll think something up myself then.
>
> > > I am really not qualified at all to hack on some way to extract the
> > > "to-be-public" parts of "camel-private.h". I would bet a really big part
> > > of my right arm that much in Evolution depend on hard to spot properties
> > > of the current implementation.
> > >
> > > Any suggestions?
> >
> > Given we are in hard code freeze, not sure; since moving it around
> > requires some macro changes, which i guess are code.
> >
> > Which locks are you trying ot access? Do you really need them?
> > Anything else in private is definitely private.
>
> I am trying to synchronize access to the url in connect() with the store
> lock. The url is really the only thing that I am currently aware of that
> I should protect (right?). The backend server is fully thread-safe so
> only locally shared resources are of any concern to me.
>
> Thanks,
> jules
>
--
adfa(evolution-2.4:20087): gtkhtml-WARNING **: cannot find icon:
'stock_insert-url' in gnome
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]