RE: A send-queue type

[<Dirk-Jan Binnema nokia com>]

Hi Sergio, Philip, all,

>-----Original Message-----
>From: tinymail-devel-list-bounces gnome org 
>[mailto:tinymail-devel-list-bounces gnome org] On Behalf Of 
>ext Sergio Villar Senin
>Sent: Thursday, November 09, 2006 11:48
>To: tinymail-devel-list gnome org
>Subject: Re: A send-queue type
>
>Philip Van Hoof wrote:
>> There was a desire to have a type that defines the role of a 
>send queue.
>>
>> A few design questions for the group
>>
>> E-mail applications often have to support multiple send 
>accounts. The 
>> user typically selects per message which send account is going to be 
>> used.
>>
>> o. My opinion is that mobile users don't care about it, and want the 
>> software to auto detect which send account should be used
>>   
>I completely agree with you.

I think that usually they don't care. I some cases they _do_ care,
for example because they should use the company smtp server for
company mails. But they don't want to specify that at message
sending time, but before, in settings. Then, the autodetection
mechanism can get it from e.g. preferences.

[ Would be interesting to use Avahi, and find the smtp-server
  in the current network. ]

>> o. Nevertheless, should the send queue register per message 
>being send 
>> which send account to use?
>>
>> o. Or should such a send queue play send queue for one specific send 
>> account (so that you have more than one send queue if you have more 
>> than one send account) (I favor this one)

>> o. If option three, should there be a TnySendQueueGroup type 
>too? One 
>> that can classify between the available TnySendQueues which 
>one to use 
>> in case the user (or developer) selected "auto detect it for me". In 
>> this case would the detecting code be implemented in the 
>> TnySendQueueGroup type (or a TnySendQueueClassifyer if you 
>prefer that 
>> name).
>>   
>IMHO, the answers are yes for both. As you said mobile users 
>don't care about the account their email program is using (in 
>fact desktop users don't care either), because the important 
>thing here is that the message must be sent.

Sounds a bit complicated... what about having a send queue, which
contains pairs <TnyMsg, TnyAccount>, and there is some 'special'
account that gets the server data from real account.

Thus, the send queue can stay a simple, singular queue, and all
intelligence goes to a 'special' account. We could even show
this special AutoDetect account as the default in the UI
combobox.

>I'm not completely sure about the use of multiple queues 
>instead of one.
>I don't see a real advantage in the use of one of these alternatives.
>Maybe it will allow messages to be sent faster because slow 
>sending accounts won't interfere with fast ones. Anyway the 
>use of the Observer pattern seems to fit very well with the 
>queue classifier idea.

Yes, I agree.

>Other question here is to decide if a given message could "migrate"
>between queues, for example if the connection is suddenly unavailable.
>The program could receive an error and suggest the user to 
>send messages by another (giving them a default choice).

Well, the 'autodetect' account can determine the actual
account and send time, and even do a second-try.

In the other case, where you explicitly to send using
account X (maybe for security reasons), it should not automagically
use another account, I guess.

Best wishes,
Dirk.