Re: Drat! (2) (Re: Todo list -- POP3 retriever) (threads/libmutt/rewrite/long subject)

[Peter Williams <peter newton cx>]

On Mon, 22 Nov 1999 14:13:06 David Pickens wrote:
> 
> 
> On Mon, 22 Nov 1999, Chris Gonnerman wrote:
> 
> > The only thing I can think of that would save my code is running calls
> > to the launch_next_job() code in a separate thread; but that fails at
> > avoiding threading altogether, which was my goal.  Contrary to popular
> > belief, GNOME does NOT require threading (proved by the system I am on
> > now, SuSE 5.2/Linux 2.0.35/libc5 with October GNOME on it).
> > 
> > Why try to avoid threading?  Because I am not the only poor sucker with a
> > non-glibc system who doesn't want to screw with it (because it works).
> 
> This is upsetting in that I'd be the last person to want to produce a mail
> client that large numbers of people couldn't use.  On the other hand,
> allowing the user to specify the behavior at compile-time might be the
> best solution.
> 

Hmmm.... I'm not too comfortable with this idea, but I think it is the best
option. Accomodating the threadless is okay, and with a few macros we should
be able to abstract pretty well... but would we want to implement code twice,
as a thread and as a state machine, or give really long blocks on downloading
of mail, etc.? State machines seem to be the best approximation of threads
but implementing the code twice is Bad.

> I looked through the new CVS code last night, and balsa is looking better
> and better.  Much of the code had changed from the last time I'd checked
> it out, and it took a bit of work to convert my older code, but I have a
> bare-bones threading patch working.  There are still 2-3 areas that I KNOW
> of that are sources of potential conflict, and unfortunately I won't be
> able to solve that until I introduce pipes and callbacks in the main
> thread.  The good news is that this doesn't appear to be too difficult.
> (Famous last words.)
> 

As above, it seems like an inelegant solution, but the best one.

> I could distribute the current patch but it does occassionally crash
> because of those known problems, and I'd rather wait until Weds night and
> have something that's not quite so 'alpha.'  I have had some pretty good
> success with the patch, however:  I managed to open and close mailboxes,
> messages, reply windows, etc., while mail was being downloaded.  Believe
> it or not, I even sent a message during the download, successfully.  (The
> GUI locked for 15 secs while the messsage was sent, but the mail download
> continued without problem.)
> 

Speaking of this... I *must* figure out how to make the GUI not lock while
sending messages.... it is SOO ANNOYING. :-) That's good to hear that the
threading code is happy.

> Other Issues:
> 
> On libmutt -- yes, I don't like it much either.  However, if anyone does
> go in to 'update' the mutt code to something newer, please talk to me so I
> can point out some changes I've made to the code (for pop3 download).  I
> know that it's been modified, at least, by others to try to get it to
> update the GUI during mail downloads, because I've had to go through and
> remove these references to get threads to work.
> 

We will keep that in mind. Does anyone know where that libmutt code came from?
Is there someone maintaining it?

> On the total re-write.  If the evolution/gnome-mailer team is working on
> an outlook clone, it might be better to start from 'the ground up' there.
> I'm interested in contributing there once things slow down, and I know
> people have raised the possibility that parts of balsa may be useful for
> them (at least once we work with the GUI a bit), but it seems that part of
> the impulse behind balsa now is to get something out in the meantime and
> to provide a client for people who don't want a full outlook clone.
> 

If we are looking for a total rewrite Evolution is the thing to work on. Also,
'working off of libbalsa' is not very helpful, because basically all libbalsa
does is mask libmutt (libmutt uses the global variables to store config 
information... eek).

==============================
Peter Williams peter@newton.cx