Re: (threads/libmutt/rewrite/long subject)

[David Pickens <dsp rci rutgers edu>]

On Mon, 22 Nov 1999, Peter Williams wrote:
...
> > 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.

Exactly (I agree) -- I was thinking that it might be possible to allow
people who can't or won't upgrade to glibc/pthreads the chance to run
without threads, but not rewrite the basic underlying code.  This will
still be a bit of hassle, and it will mean that people who take advantage
of this 'option' will have to live with the blocking, but at least they'd
be able to run balsa.  On the other hand, this will become a major
undertaking if we hope to put mail sending calls etc. in threads.

How many users (proportionally) can't use pthreads?  How many won't by the
time we have something ready for mainstream use?  And what stands in the
way of upgrading?  (In other words, can we just expect that users will
upgrade to glibc/pthreads by the time this is available for popular use,
assuming of course that reasonable PCs can do this? 486+?)

David



> 
> > 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
>