On 28/08/2018 15:16, Michael Stone wrote:
Well, we've discussed this at some length now and I can only say that, in my opinion and experience, NNTP seems overwhelmingly advantageous to me in the scenario of a private discussion group (i.e. for a discussion list much like this one and for the common profile of its members). I recognise that other people and other types of user prefer access methodologies (e.g. email lists, web forums, app-based, IM-style, etc.) but none of that, to my mind, lessens NNTP's ideal applicability to getting private discussion group messages from place to place (the front end UI/UX being a different thing again). Remember that we're having this discussion over email. As you observed above, The key advantage of NNTP over email/SMTP in terms of bandwidth efficiency is that, with NNTP, messages are only sent to users when they explicitly ask for them. This is more bandwidth-efficient than an email-based list since the email-based list must send out messages to each and every user whether or not they want them. There is also a management efficiency advantage to NNTP in that it doesn't have the deliverability problems that plague email nowadays. and none at all over a well implemented modern web based discussion with a cacheable REST interface. To my mind, a REST protocol has a different (but overlapping) use case to NNTP or email lists. I know of no standard, open REST protocol that replaces either NNTP or email discussion lists, for example. An often implicitly stated requirement (for certain types of users) in the private discussion list use case is compatibility with a standard mail or Usenet/NNTP client. Clearly, this is not important for every user (and more and more users prefer web UIs nowadays, albeit often in ignorance of other ways to do things) but I nevertheless take the view that NNTP has its place and is, technically speaking, a near-ideal protocol for distribution of discussion groups. This is the issue with what I called "moderator-ability" above. You seem to have it the wrong way round. I am not "offering a closed environment with close to zero users as a counterexample". It (i.e. NNTP in private discussion groups) is not a counter example of or to anything. It is, in fact, the specific issue under discussion! It is *you* who introduced the historical problems of Usenet and used them as erroneous reasons to reject NNTP for the specific use case under discussion, that is private discussion groups. I "brush off" the problems of Usenet because they really do have nothing whatsoever to do with NNTP in the context of private discussion groups, for the reasons I have specified. You were conflating Usenet the system with NNTP the protocol and thereby blaming NNTP for problems that would have plagued Usenet even if it was still based on UUCP and not NNTP. Additionally, I got drawn into historical discussions about Usenet with you but the overall conversation from the perspective of my involvement is still about the applicability and suitability of NNTP for private discussions groups (i.e. something for which it is ideal in reality) and the way that NNTP's involvement in Usenet does not make NNTP a poor protocol for private discussions groups. But I'm happy to stop talking about usenet...except that you bring it up again: But why did you ever mention it, when it was not and is not relevant to the issue at hand? I remind you that I only joined in a discussion of Usenet because it was you who introduced it. I joined in specifically to point out how your mention of Usenet was irrelevant in this context. You've asserted it many times, but you haven't actually shown with numbers how it's more efficient in practice to any degree that matters in the real world. I have in fact (a) pointed out specifics of how NNTP works better in the context at hand, and (b) pointed out how your negative view of NNTP in this context was based upon an erroneous conflation with the problems of Usenet that were not caused by NNTP. If you prefer to interpret the specifics i have provided as assertions then so be it. We'll have to agree to disagree. making it interoperate with the expectations of a modern web forum is hard--potentially impossible without proprietary extensions, at which point you've thrown away the entire point of sticking with NNTP instead of using something else. I disagree. You seem to me to be finding problems where there are none in practice. A great deal of this seems to be about expectations. Could it be that you are expecting something that is, to my mind, unnecessary or irrelevant (i.e. not part of the target use case). I don't want to go into too many details but, at its heart, a forum or discussion group of any sort is about message content. How you get it to and from users is the question and different methods can suit different users, types of users, and audiences. There is no fundamental reason why one method has to be used to the exclusion of all others. Content posted to a web forum (via web browser or via app front end or via some REST client) can perfectly well be distributed (complete with graphics, text effects, images, even binaries (!!) ) to participants via email or NNTP. Email and NNTP protocols as widely deployed in client software and in other standardised servers (email in this case) fully support the necessary message content standards. Similarly, there is no fundamental reason why it is difficult for a user to create a message in their email or NNTP client, send it to the appropriate address or newsgroup, and have it appear in a web forum (again complete with text, text effects, graphics, etc.). There really are no particular difficulties with this and no particular need for proprietary extensions to any standard protocol. There are plenty of services around today that implement perhaps one or two out of the main three of these access methods (the main three being email, NNTP, and web, with NNTP being least common) but few that implement all three. There are a fourth and fifth access methodology, of course, which are REST (mostly non-standardised) and RSS/ATOM. (I am not forgetting ATOM Publishing Protocol but this has even less deployment in practice than NNTP and there are certainly fewer ATOM Publishing Protocol clients in the wild then there are NNTP and email clients). The conceptual split between transit and reading functionality is a lot of legacy to carry forward if you're basically trying to create a reader interface for smart clients. Enough to make it debatable whether it's worth trying to implement all that vs exposing a REST API. I don't see it as either/or. REST and other access methodologies (for reading and/or writing) can and should co-exist. I'd love to see a modern, open standard REST-based general message posting/reading protocol to replace NNTP in a discussion group/forum context and to standardise non-web browser client access to web forums, but the call of the walled garden makes this unlikely. What we have instead is a proliferation of REST standards, often with their own walled garden or Ts&Cs constraints. Nevertheless, older access methodologies still have their fans and, in actuality, are still relevant today and can be inter-operated with more modern services quite easily. There are those who want them (albeit certainly not to the exclusion of other access methodologies). As this overall thread has shown, many of the people who prefer email or NNTP access methods are the kind of people who are members of this mail list.
I think web forums have become the de facto replacement for groups accessed by NNTP because they were, more than anything else, simpler to use and access. They were just there in people's web usage. Other features in web forums came along because they were possible (not that there was, initially, demand for them). Now such secondary features are expected by many classes of user. But, despite this, NNTP and web forums (and other access methodologies) are not mutually exclusive. To be clear, the kinds of users who choose to access a discussion group of some sort via NNTP or email (one that most users access as a web forum) are unlikely to care that they don't see a Like button. On the other hand, any modern NNTP or mail client can in fact show them a clickable Like button that actually works (unless they've chosen to disable complex HTML, which is fine of course). As much as greybeards don't understand why the like button matters, it's really hard to convince actual users these days that the reason you don't have one is that they don't need it and you know better than they do. I wouldn't attempt to do such a thing. :-) If I was designing a discussion environment from scratch, there's no way I'd design it without a web front end as one possible access method. But one should not ignore the fact that the greybeard population is a large one and actually is getting larger. Even as the percentage of technical users on the Internet continues to reduce as a proportion of the Internet population as a whole, the absolute number of technical users who would like or might like standardised access methods and tools grows. Their voices may be diluted but are no less real. As individuals, they may prefer to use different UIs and different access methodologies from different places: A Tapatalk-like UI on their mobile device (speaking REST to the back end), a NNTP read/write feed on their preferred main Usenet/NNTP client, or an email read/write feed on their preferred main email client (accessed on mobile and/or desktop), and perhaps a web browser UI for occasional quick access from a different form factor device. All of these methods can and should co-exist, in my opinion (ideally speaking). There are a lot of other usability issues that basically boil down to the change in user behavior from using a smart client at one location (possibly telnetting/sshing into there from elsewhere) to using a variety of dumb clients to access centralized resources. Protocols that transfer dumb messages but allow a lot of endpoint customization are great in the smart client model but tend to not have a good user experience in the dumb client model. (And vice versa--if you have the ability to highly customize a specific workstation, it's frustrating to not be able to.) Given demographic and technological trends, ignoring the dumb client paradigm is short sighted at best. I agree. Nothing I've said should be taken to mean that I ignore the dumb client scenario. But I also recognise that there are many use cases with many types of user. This is exactly what I was talking about earlier. Yes, it's theoretically possible. But for a variety of real-world reasons, large scale NNTP-accessible web forums haven't succeeded. (If you look, you can find a lot of attempts that never really gained much traction.) It was more practical in the tapatalk case to invent a new protocol than to use NNTP. I'd suggest that it's worth understanding why rather than just insisting that everybody is wrong and NNTP is the answer that they just haven't figured out. Indeed, but our discussion has ranged in various directions and are beginning to conflate somewhat issues. I'm not pitching NNTP as a replacement for this sort of scenario In the original context of this sub-thread, that is access to discussion groups like this one, NNTP has advantages. This is its ideal use case alongside email. It is the fact that both email and NNTP are standardised that appeals to users in this context, as well as the cleanness and efficiency of these protocols compared to web browser based access or other UIs or access methodologies. -- Mark Rousell |