On Fri, 15 Nov 2002 15:31:33 +0100 Xavier Nodet <[EMAIL PROTECTED]> wrote:
Hi Xavier, sorry for the delay -- as usual, I was going to try to compose a very long and informative answer but finally realized that I'd never have the time to do it so am going to write a long but uninformative one :-) XN> As I was not satisfied by my current newsreader (XNews), I'm not surprized. Most of the GUI newsreaders are really bad. When I was still using one, Free Agent was the least bad one but then (~5 years ago) I switched to slrn and never regretted it. XN> Handling of subscribtions XN> ------------------------- XN> XN> I knew that it was possible to get the list of the groups available on XN> a particular server, but I had a hard time finding the way to get this XN> list. The answer is that one must first create a NNTP folder with just XN> the name of the server, check the 'Has subfolders' option, and then do XN> a 'Browse subfolders'. Then one can either add all groups (maybe an XN> option if you have your own personal news server, as I do, but a big XN> mistake if your server has several thousand groups...) or choose the XN> ones to add in a tree. Yes, this is hardly intuitive. It was done simply because it took no extra effort at all to make this work (we simply use the same logic and the same code as for all the other folder types) but it's definitely not the way to do it. XN> Note the list of groups is asked again to the server each time one wants XN> to expand a node in the tree (and they are all folded to start with...). XN> This is obviously useless. Unfortunately (well, AFAIK) there is no possibility to retrieve just the groups with the given name (e.g. matching a RE) in NNTP. And retrieving ~35000 from my NNTP server is slow indeed, even over a fast connection. Of course, we must cache the list of all groups once we retrieved it. I'm surprized cclient doesn't do it internally. But then its NNTP support is more of a joke than anything else. XN> I would recommend the way XNews does this: display a list of all the XN> groups, with their description, and allow the user to filter this list XN> using parts of words in the name of the description, initials, ... XN> Better yet: display the combined list for all servers, and have the user XN> choose the server from which to get the groups, if there are several). Yes, this would be a nice way to do it. XN> Another point: currently, if you browse for sub-folders, all the groups XN> you choose are added in a hierarchical fashion: if you add e.g. XN> sci.geo.satellite-nav, sci.op-research and fr.misc.droit.immobilier, you XN> get a hierarchy like this: XN> XN> My server XN> |__ sci XN> | |__ geo XN> | | |__ satellite-nav XN> | |__ op-research XN> |__ fr XN> |__ misc XN> |__ droit XN> |__ immobilier XN> XN> I would very much prefer something like XN> XN> My server XN> |__ sci.geo.satellite-nav XN> |__ sci.op-research XN> |__ fr.misc.droit.immobilier Actually I think that I like the version above. Ideally, I'd like to have separate nodes for all hierarchy levels but the last one, in fact. XN> I believe that for most people, it will be much better But I agree that for a normal user it's not ideal. The dialog mentioned above should create all the groups chosen in it as siblings -- this is already possible and quite trivial, of course. Unless you're going to work on this, you should probably enter this in the bug tracker. XN> Opening a group XN> --------------- XN> XN> When one opens a group, the current behavior is to download *both* XN> headers and then text for *all* messages. Again, this may be correct for XN> a local server which the user controls, but not for the general case. Hmm, so cclient even doesn't use XOVER? This would be dumb... The logic here is the same for all folders: we only ask for the messages we must show on screen. But maybe it decided to download everything because we're asking for flags? This would need to be checked. XN> Downloading the text of the messages itself is obviously a bug. Yes. XN> Actually, this is because c-client (as we use it, at least) insists that XN> the exact size of the message must be known even if we are only XN> interested in the headers. Yes, we had the same problem with POP... XN> I have a very simple patch, but this prevents to ever get a correct XN> display for the size (actually, what is displayed is the size of the XN> headers). But with POP there is LIST which can be used to get the size -- and I'm sure there are NNTP extensions allowing to do it as well. So, again, we should patch cclient to use them. XN> Reading a group XN> --------------- XN> XN> The problem here is that the only operation that c-client handles on XN> messages in NNTP folders is to delete a message. So when a group has XN> been opened, new messages do not become read when the user selects them, XN> and the only way to get rid of read messages is to answer Yes to the XN> question asked when leaving the group: 'Do you want to mark *all* XN> messages as read'. This actually marks them deleted, by the way. Yes. This is not that unusual for news clients, mind you: for example, slrn marks the read messages with 'D' flag too (I never really paid attention to this but now I've just realized that this 'D' can't stand for anything else but "Deleted"). OTOH, we could mask this difference at GUI level. XN> By the way, this question was asked even when leaving a group where all XN> the messages were already read. This is corrected. Thanks! XN> The 'Size' column in the folder list should display the size of the XN> messages in number of lines. My understanding is that this was planned XN> as such, but the information is not there: while the headers of the XN> message actually have the information, it is not available in any data XN> structure that c-client and/or Mahogany handle. cclient size struct does have lines field but I've never seen anything but 0 (meaning "unknown") in it. I would have thought that it is used for NNTP and am surprized that this is not the case. Again, the answer is in cclient code... XN> Other stuff XN> ----------- XN> XN> I suppose that if all the problems above were solved, M could be XN> considered a news-reader, which is not the case currently. But it is already a news writer :-) XN> PS: the only thing that XNews does not handle correctly is the XN> 'Reply-by-mail' feature Mahogany doesn't handle it at all... There is a bug report (which I created myself) about it though. XN> but if we do not eat our own food, things will not evolve... You're right, of course. I know that Mahogany improved dramatically (especially under Windows) since I started to use it as my only mail client. The trouble is that slrn has (very good) scoring support and I can hardly imagine reading news without it. But maybe I should try :-) Anyhow, knowing what we have to fix is a good first step -- thanks for looking at this and writing this report! VZ ------------------------------------------------------- This sf.net email is sponsored by: To learn the basics of securing your web site with SSL, click here to get a FREE TRIAL of a Thawte Server Certificate: http://www.gothawte.com/rd524.html _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
