On Sat, 2002-07-06 at 06:55, Jeffrey Stedfast wrote: > Er, I probably should have mentioned what these changes were: > > There is no longer a Send Later menu option in the composer (nor does > there exist the "postpone" signal anymore) > > With the changes I had proposed, the difference between Send Now and > Send Later was basically nothing and so it really just made the whole > point of Send Later pretty useless. I also proded Outlook to see what it > did, and it turns out it doesn't have a Send Later either - it just as a > "Send" button/menu-item that appends the message to Outbox and queues a > send operation. This is also what we do now...
So what if you do want to do send later? or you're not online and dont want it to crap around trying to send to nowhere? I dont know about your changes to the get send type either, they look pretty dodgey. Then again the whole mechanism for specifying dual provider types is dodgey anyway. > Jeff > > On Fri, 2002-07-05 at 17:18, Jeffrey Stedfast wrote: > > This code (though slightly modified) is now committed, but I am still > > taking suggestions (especially as to the preferred way of combining > > mail_receive_url() and mail_send() so as to minimise code duplication). > > > > Jeff > > > > On Wed, 2002-07-03 at 20:13, Jeffrey Stedfast wrote: > > > (this is being sent to e-h@ also since this is mostly meant to encourage > > > discussion.) > > > > > > There have been a number of complaints that messages don't get saved to > > > Outbox between the time the user hits the Send button and the time at > > > which the message is actually sent (and then saved to the Sent folder). > > > > > > examples: > > > http://bugzilla.ximian.com/show_bug.cgi?id=23594 > > > http://bugzilla.ximian.com/show_bug.cgi?id=26112 > > > http://bugzilla.ximian.com/show_bug.cgi?id=20495 > > > > > > (Keelyn has also expressed that she would like it to work this way since > > > that is what Outlook does, in case that matters to anyone) > > > > > > The attached patch changes the behavior such that composer_send_cb() > > > does mail_append_mail() rather than mail_send_mail(). The async callback > > > does pretty much the same thing as before, but if the struct _send_data > > > passed in has send->postpone == FALSE, then we invoke a send (which > > > sends everything in Outbox). > > > > > > This pretty much means that except for the send->postpone option, > > > composer_send_cb() and composer_postpone_cb() are exactly the same. > > > > > > Something I noticed while merging the code of these 2 functions was that > > > they basically did exactly the same thing anyway, except that > > > composer_postpone_cb() would spawn a thread to append the message to > > > Outbox but didn't wait for it to finish before destroying the composer > > > widget. The obvious problem with this is that if the append-to-Outbox > > > failed, you'd have potentially lost data. > > > > > > Anyways, that problem is also solved with my newer implementation. > > > > > > Things I predict NotZed will not like (tm): > > > > > > - a new function that duplicates a bit of code: > > > mail-send-recv.c:mail_send() > > > > > > I'm thinking that I could just use mail_receive_uri() and do the bit of > > > work it is to get the default transport url in mail-callbacks.c (it's > > > only like 2 or 3 lines of code). > > > > > > However, this would also require receive_get_type() (and other parts of > > > mail-send-recv.c) be fixed to handle the case where a provider is both a > > > store and a transport. We might also need to change mail_receive_uri() > > > to take another arument specifying whether or not it should send or > > > receive (or both?) with the passed-in url. All in all, not a major > > > problem to solve. > > > > > > > > > Okay, well - I guess that's all I have to say for the moment. > > > > > > Jeff > > > > > > -- > > > Jeffrey Stedfast > > > Evolution Hacker - Ximian, Inc. > > > [EMAIL PROTECTED] - www.ximian.com > > -- > > Jeffrey Stedfast > > Evolution Hacker - Ximian, Inc. > > [EMAIL PROTECTED] - www.ximian.com > > > > > > _______________________________________________ > > evolution-hackers maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution-hackers > -- > Jeffrey Stedfast > Evolution Hacker - Ximian, Inc. > [EMAIL PROTECTED] - www.ximian.com > > > _______________________________________________ > Evolution-patches maillist - [EMAIL PROTECTED] > http://lists.ximian.com/mailman/listinfo/evolution-patches _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
