Re: [Evolution-hackers] Diary replaying on IMAP accounts

On Mon, 2008-01-21 at 13:17 +0100, Philip Van Hoof wrote:
> On Sat, 2008-01-19 at 10:48 -0500, Jeffrey Stedfast wrote:
> > 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.
> Hey Jeffrey,
> Do you think that this should be committed in upstream Camel too?
> I'll pass the question to Matthew too. I'm not sure whether the function
> should indeed always return TRUE in case of RESYNCING state. Perhaps
> it's better to adapt the return value of the function and replace all
> uses of it? Perhaps TRUE in case of RESYNCING is fine?
> There are indeed multiple solutions to solve this.
> Note that once the diary starts working, you'll have one or two small
> bugs in the diary code too (a variable diary->folders becoming NULL at
> some point, yet still being used somewhere).
> I wonder whether these diaries ever worked? So suddenly making it work
> might introduce new bugs in Evolution too.
> Note that the behaviour is that the APPEND command will fail, Camel will
> react to that failure by reconnecting and forgetting about the diary.
> The result can be called data loss .. since the message that was to be
> appended is now only locally available, and not appended remotely.
> It's kinda hard to spot this bug, as it requires working with another
> E-mail client (if you open the message, it'll just work since it's
> cached locally, and it'll also be in the summary since the summary
> supports temporary UIDs).
> (sounds like severe to me)

To be honest, I have no idea what the side effects of changing that code
to return TRUE for the RESYNCING state are. That's one of the problems
with a tri-state that isn't really a tri-state :\

As you mentioned, having it return FALSE is clearly not "correct" and
returning TRUE may introduce some bugs :\

As far as I know, there are some bugs regarding offline usage not
resyncing properly when going back online, so you may have found the

I'll let the current maintainers make a judgment call on whether to
accept this into mainline Camel or not (looks like either way, there's
gonna have to be some attention given to this area of code)

Sorry that I can't be any more "concrete" than that :(


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]