RE: A send-queue type

[Philip Van Hoof <me pvanhoof be>]

On Thu, 2006-11-09 at 15:01 +0200, Dirk-Jan Binnema nokia com wrote:


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

You mean: it would be interesting to make tinymail flexible in such a
way that the developer could create an implementation that uses Avahi
for detecting the preferred SMTP server that the TnySendQueue pieces of
the framework should use   ...   :-) ?

I agree with that. I would disagree with a design that glues tinymail to
Avahi.

One word: CHANGE. And, "to be adaptive to it". Today it's Avahi,
tomorrow it wont be. Tinymail is also for tomorrow.

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

I'm more in favour of having multiple TnySendQueue instances grouped by
something that I would call a TnySendClassifier which would implement
detecting which TnySendQueue to use.

One TnySendQueue would then have a one-one relation with one
TnyTransportAccount

Why I am in favour of that? Well because it would simplify the
implementations I think.

However. We need to draw this and try it, I think. And then be flexible
about refactoring it to that other idea. By that I mean: don't put the
API of this in stone. Because, I think, this is something of which the
real-world will tell us what the best design is (the developers whom are
going to be using it and their feedback about it).


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

The combobox is UI, that UI idea is possible with both ideas.

A singleton doesn't mean that it's more simple. A singleton also implies
much more locking and other such complexities. I know that "a singleton"
sounds "easy" and "simple", in reality it's often the exact opposite.

"Avoid singletons" is a wise design principle. However, both have their
singletons. In case of my idea the singleton would be the classifier
that will detect which queue to prefer. For your idea it will be the
queue itself that will be the singleton and that will have to implement
a lot of the classification too.

My idea is:

- The queue implements the complexity of making it asynchronously and
implementing the observer pattern

- The classifier implements classification and detection 


For your idea it would be (unless I misinterpreted it):

- The queue implements the complexity of making it asynchronously,
implementing the observer pattern and implementing classification

- A detector tells the queue which classification to prefer.


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

Those are user interface problems. But important to know, because the
infrastructure must allow the user interface developer to interfere.



-- 
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
blog: http://pvanhoof.be/blog