Email and News are not the same thing, but they share many features. It is therefore not surprising that most newsreaders also read email. Certainly, for most users, email and news handling are so similar that the differences are not significant. However it would seem that there are two possible 'models' an email/news reader can follow. I changed from Posty to Messenger Pro and got caught totally unaware by the use of different models. So if you are thinking of changing, the following tale may assist you. Even if you are not thinking of changing, maybe you will find it interesting. Maybe I will widen the scope (in due course) to include Pluto.
Multi-user News Reader
Consider, for one model, maybe a group of students networked together all reading a different selection of news groups, via a common internet 'gateway'. In such a group, the news handler would best store all required news items as a single 'database' on one central 'server' - usually the same machine that is connected to the internet, so server and gateway are the same machine. The news viewing software is be run on each users machine (the clients) and would interact with the news database on the server machine to allow all users to view the available news.
Clearly, in such a situation, each user's machine must keep its own separate note of what each user has read, posted, answered or whatever. All information about traffic (held in the status flags) is associated with the user. Each user would, of course retain his own signature and his own email address, to which email replies to his news would be sent. So each user must have one email box, and one alone.
Mail Sorter
For the second model, consider a small business, operating an email system. In a business, incoming paper mail is normally sorted in a pigeon-hole sorter. One slot for enquiries, one for incoming purchase orders. One slot for incoming invoices. Another slot for statements and so on.
After sorting the incoming mail, the same person will very likely deal with most of the sorted mail on a box by box basis. So here we have a single 'user' with lots of mailboxes. Email for small businesses is no different to this and, as most small businesses are still principally paper based, and are likely to be so for many years, to my mind an ideal email system should model itself on this paper system, which, incidentally, is exactly what Posty (in its latest incarnations) does.
The astute amongst you will have noted that any program based on the 'News' model simply cannot cope with such a multi-boxed system. The single human user has to log off and log in as a separate 'user' to the computer.
Although it is a workable system (for the masochist) to my mind such a system is intolerable because I want a computer to help me work and help keep track of transactions, not to cause me extra work and cause me extra confusion! And, yes, I am not as young as I was - it could be that younger users can organise their brains better in Messenger's way, but then I probably also must admit the possibility that pigs are evolving wings!
Yes - I can give simply myself 'postmaster' status when I do have access to all mailboxes and can answer any indiscriminately. The problem then is that all the replies I generate will carry my own 'postmaster@' reply-to address and sig. Not at all what I want, as any returning correspondence then ends up in the 'postmaster' box.
There is also a second problem with this: if I forget myself and am logged in as 'support' rather than 'postmaster' then I will not see postmaster's view of the status of the emails and the ones I answered as postmaster will now appear to me as unanswered!
This to me is a ludicrous situation. I, a human have self-awareness. I am not an actor and am not in the habit of donning different personas! If I answer an email, I want the status of the email to show whether it has been answered. It is totally ridiculous to have the status of am email depend upon the viewer!
As far as I can see, for any single email - if a customer writes to the business then he expects a reply on behalf of the business. Email is not a free-for-all discussion (as is a newsgroup). Once an email has been answered, then that email has answered, just as a letter is answered. With paper, it is usual practise to rubber-stamp the letter as 'answered'. No business in their right mind would require each person to keep a list of letters the has answered and require them to consult other persons lists if the need arose! I see no reason at all why email should be different! In normal use, any letter or email should not be able to generate two replies - unless of course one was by way of being an acknowledgement of receipt of a mail that required more investigation before being fully answered. So (for me, at least) the status flags of an email must be tied not to the user - but to the email itself.
In this second model, if the email is dealt with by 'sales', then 'support' or 'postmaster' or anyone else having legitimate reason to read the email will see that the email has been answered. In the first model - they will not.
Both models, to the average user, degrade to virtually the same thing: if there is only one user (with only one mailbox), then it doesn't matter at all where the status flags are hung!
Messenger is a newsreader of the first type, intended for a network of users, even though RComp's www site currently 18th August, 1999 describes it as a 'Single-user' email and news reader. In my opinion it is not suitable for a single user with multiple mailboxes, unless that user is prepared to masquerade as several other users, as suits the software. So, currently it does not well handle a business user of the second type, although (since I caused a flame war by pointing out this idiosyncratic approach to emails) steps are being taken.
Pluto on the otherhand, is much nearer to the first type of program. 'Users' (i.e. email addresses) are clearly attached to the boxes, rather than to the user. Nevertheless, Pluto can have a 'user' in the sense of a person 'signing in' at the beginning of the session, and this user's email address wil be used, where a bos hasn't got a user already defined. Pluto is however a 'single-usrr' program in that is has an internal database and is not designed for multi-user access on a network. If you really do need the matrix model, then Pluto's not for you. If you are a normal user, you may just find Pluto simpler to understand!
Pluto is not perfect: however, having gotten far enough into Messenger to realise how it was organised and that (I believe because of this matrix organisation) it did not behave in ways I could predict, I swapped to Pluto. Pluto doesn't always behave as I expected either but in Pluto's case that seems to be because its instructions are somewhat lacking rather than that it is too complex!
Whereas Messenger concentrates on doing the 'Correct' thing, Johnathan Duddingtom has written Pluto to do what his users want to do: he has expanded it, responding to requests from users. So Pluto does what users want - regardless of whether it is 'correct'.
Clearly, in the multi-user environment described above, the matrix model is, indeed necessary and therefore 'correct'. However, outside this multi-user environment it is un-necessary. Moreover, the matrix model virtually dictates the use of a two program approach: database and reader. Bit such a dichotomy places sever constraints on the program and makes it massively more complicated. Pluto does not use a separate database, which makes its structure a lot simpler, removes many programming constraints and has side effects of making the program smaller and faster. In comparison, Messenger's constraints must severely complicate its programming!
Both programs have grown with time - both in response to user requests, but unfortunately the documentation for neither program has kept pace. This (although regrettable) is understandable: programmers enjoy programming. If they enjoyed writing, then they would be authors! Furthermore it is undeniable that it is almost as much work writing the documentation for a program as it is writing the program. To keep documentation up with a moving program is a near impossibility!
In Pluto's case, this probably means that few users use (or are even aware of) many of Pluto's features. But that's a problem shared by all products of a technical nature.
One interesting thing about Messenger users as a whole is that they 'define' the NewsReader model as being 'correct'. So I was told that it must have been my requirements that were wrong. Andrew of RComp, who sell Messenger-Pro, told me in no uncertain terms, that I am organising my business wrongly and Messenger is the correct way to do it! This 'certainty' is a character trait that is anathema to me. I will accept suggestions, weight them on merit and make my own decision. It is my firm experience that anyone who 'knows' the answer in such a prejudiced fashion is more likely to be wrong than right and is best avoided at all costs. The most trustworthy expert is always one who believes he is correct, based on his past experience, but wants to find out more - as there is always another viewpoint and he would be delighted to have someone prove him wrong and broaden his view!
I have therefore decided, in view of this prejudiced, big-brother approach, to cut my losses and bin Messenger Pro. But the distinct feeling I get is that Messenger is a programmers program - not a user's program. I believe Pluto, on the other hand, is probably a user's program.
I feel a distinct foreboding at this perception. Users as a whole expect new computer programs to be daunting and hard work. So we users never complain, never make suggestions. Anyone who criticises is seen as being merely awkward, or simply stupid. If we users do not complain, then more programs will gp the way of Messenger, written by programmers for use by programmers. When this happens, RiscOS will die!
Currently RiscOS is the only User's OS which is also a Programmers OS. It is loved by programmers and users alike. But we, the true users, must not let the programmers take over! We must make sure programmers write not only programs that are good to use, but instructions which make them friendly to new users.
Writing such instructions is certainly not an easy task - but I think it is possible. However, it seems to me that I now need to prove this point! So I probably have to cooperate with a programmer and write them myself.
Now how on earth did I reason myself into that position? I am in process of expanding Pluto's instructions, mainly for my own benefit, so they ae not (yet) publicly available. I find myself hampered in doing this, as I do not have JSD's co-operation, and I do not have his understanding either!
For more thoughts on technical manuals, see Manuals
I have tried to differentiate facts from personal opinions in this essay. I believe I have made it clear that neither program is perfect, that both are of similar worth to the average user, so choice is mainly a matter of personal preference. Both have email lists with helpful readers. I should have made it clear why I have chosen Pluto, and why the reasons for my choice are not neccessarily the same as yours! So I hope this page helps you make up your mind!
If you buy Pluto - or, for that matter Messenger Pro, as a result of this page, please let Jonathan Duddington or R-Comp know.
I'd also be interested in feedback!
This page's URL: http://www.4qd.co.uk/compute/emailers.html