Community
Participate
Working Groups
In the old days, if you wanted to post in the newsgroups, there was this user exquisitus for access credentials. This is a well known user and we use it for testing the NNTP protocol. One of our GSoC projects is the integration of news into the workbench. It would be nice if every newsgroup participant is using his/her own unique Eclipse ID (clumsily named "bugzilla account") instead of posting with this generic user. What is the status of this exquisitus account? Can it go? Do we want people to post anonymously in our forums?
If we were to kill that login ID, those who have already configured their NNTP clients with it will get an error, correct? I don't think allowing anonymous NNTP posting is a good idea; at least exquisitus requires a real person (in theory).
(In reply to comment #0) > It > would be nice if every newsgroup participant is using his/her own unique > Eclipse ID (clumsily named "bugzilla account") instead of posting with this > generic user. People can already post to the newsgroups using their Bugzilla ID -- via the forums. The problem with Bugzilla auth for NNTP is that, for those who are not aware that their email address will be accessible to all, unmangled, will have a major fit. Also, extending inn (our nntp server) to support a bugzilla login would likely not be trivial. > What is the status of this exquisitus account? It is still being used for NNTP. > Can it go? I'd rather see NNTP go. > Do we want people to post anonymously in our forums? Not unless everyone is willing to sift through a high ratio of SPAM. Closing as WONTFIX since the workaround is to use the Forums.
> I'd rather see NNTP go. Are the forums not a front-end to nntp?
The old newsportal was a front-end because it lacked the functionality to stand on its own. Since the Forums is much more feature-rich than the NNTP, and if we examine posting tendencies, I'd suggest that it's quite the opposite -- NNTP is now second-class compared to forums.
What I meant to ask is: Are the forums using the NNTP server to store the postings or do they have their own database and replicate to the NNTP server? What software do you use for the forums so I can take a look.
(In reply to comment #5) > What I meant to ask is: > > Are the forums using the NNTP server to store the postings or do they have > their own database and replicate to the NNTP server? > > What software do you use for the forums so I can take a look. I found it: fudforum: http://cvs.prohost.org/index.php/Newsgroup_Manager
> we examine posting tendencies, I'd suggest that it's quite the opposite -- NNTP > is now second-class compared to forums. The protocol is ancient but at least it is one (a protocol).
> The protocol is ancient but at least it is one (a protocol). I totally agree with you. I have nothing against nntp; however, by now it is mostly abandoned (or so it seems, anyway), as is development on the major popular nntp server software.
> Are the forums using the NNTP server to store the postings or do they have > their own database and replicate to the NNTP server? The forums (FUDforum) has its own database. Forum posts are replicated to nntp, and vice-versa.
> > The forums (FUDforum) has its own database. Forum posts are replicated to > nntp, and vice-versa. Thanks! We are writing a forum workbench integration for the next GSoC. It knows NNTP so there is our glue. It would be great if we could program directly against FUDForum instead of using NNTP but the problem is that they have a very limited API [1] Let me see if I can get them going on some kind or REST structure. Do you have any contacts over there? [1] http://cvs.prohost.org/index.php/FUDAPI
Yes, their API is very limited. Instead of a REST API, one thought I had that could likely solve two problems at once is if there was an NNTP front-end to the forums (ie, an NNTP server written in PHP which sources the data from the MySQL database). With this type of setup there would be no synchronizing two different systems, and your workbench could still talk to the forums using a known protocol and known auth mechanisms. In the end that may be too much work...
