[Evolution-hackers] Re: camel-private.h not installed

[Jules Colding <colding omesc com>]

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