ROBINSON@BITNIC.BITNET (Andrew T. Robinson) (02/09/90)
Richard, I'm not trying to argue that there should be no technical direction to the network. If that's how it came across than I misspoke and I apologize. My concern is more with the way services are developed on this network. A lot of people DO accomplish a lot on BITNET, but a lot more find BITNET too cumbersome for words. I have been using this network since 1982 and I'm frequently not sure how to answer a question like "Where do I go to find information about such-and-such." This is assuredly ignorance on my part, but I maintain that even ignorant people should be able to locate information quickly and easily--WITHOUT having to go to the "nearest LISTSERV", do an INDEX command, and try to guess what files/lists are applicable to the problem. Software like VM NETNEWS is a step in the right direction, and I think that most users would choose NETNEWS over raw LISTSERV (that is based on my experience and may not be applicable in general). However, like LISTSERV and NETSERV, NETNEWS does not seem to encourage imitators. There is no specifications document that would allow enterprising programmers on other systems to develop compatible programs. BITNET is a software oligopoly (at best). I think we need to open the "market" up by specifying the services we want to provide and allowing people to develop their own implementations.
SCHAFER@RICEVM1.RICE.EDU (Richard A. Schafer) (02/09/90)
On Fri, 9 Feb 90 09:41:36 EST Andrew T. Robinson said: >My concern is more with the way services are developed on this network. >A lot of people DO accomplish a lot on BITNET, but a lot more find >BITNET too cumbersome for words. I have been using this network since >1982 and I'm frequently not sure how to answer a question like "Where do >I go to find information about such-and-such." This is assuredly >ignorance on my part, but I maintain that even ignorant people should >be able to locate information quickly and easily--WITHOUT having to >go to the "nearest LISTSERV", do an INDEX command, and try to guess >what files/lists are applicable to the problem. I have no disagreement with this. Without question, there's a lot of work that has yet to be done on making BITNET easier to use, even for knowledgeable users like ourselves. Like Andy, I frequently flail around for a while looking for how to find things. Of course, without meaning to take a swipe at Andy or any of the current BITNIC staff, I feel that's an area that BITNIC *has* been charged with serving and hasn't done a good of even keeping their own files up to date. >Software like VM NETNEWS is a step in the right direction, and I think >that most users would choose NETNEWS over raw LISTSERV (that is based >on my experience and may not be applicable in general). However, like >LISTSERV and NETSERV, NETNEWS does not seem to encourage imitators. >There is no specifications document that would allow enterprising >programmers on other systems to develop compatible programs. Sorry, but here I disagree totally. There is a specifications document, and it's RFC's 977 and 1036. Taken together, they should describe enough to allow someone who wanted to write a NETNEWs-like beast for their environment to create something which could communicate with the rest of the Usenet world. These RFCs don't define how the user interface is built but I don't think this is the problem. (I might add, of course, that rather than talking about NETNEWS imitators, we should note that NETNEWS is a late-arriving (and in some ways lesser functional) version of a facility that has been around in UNIX sites for a long time.) >BITNET is a software oligopoly (at best). I think we need to open the >"market" up by specifying the services we want to provide and allowing >people to develop their own implementations. Back to full agreement. The only point I'd raise is that I believe that BITNET should be providing something more than "OK, gang, here's something that we think every environment should develop, now go to it." The history of BITNET suggests that what will happen is that the VM sites will do it first, then maybe some VMS and MVS implementations will appear, followed eventually if ever by the rest of the network. In the meantime, the non-VM sites will complain that no one ever thinks about them, and the VM people will shout back "If you want to do it, go do it yourself!" BITNET needs to provide some support for helping people develop the software, perhaps by providing some form of BITNET grant-funding. No, I don't know where the funds would come from, but surely someone at EDUCOM knows *something* about raising money, right? EDUCOM is supporting a program that honors people who write software for academic use. I forget what it's called, but the EDUCOM conference I went to in Washington, D.C. in 1988 had a big whoop-te-do, including glitzy video-tape of each winner's software in action, plus a trophy and a monetary ($5000 for 1st place?) price for the best of breed. (You could even buy a copy of the video tape to take back and show to your cohorts!) While these programs were all academic instruction, and usually PC or Mac based, why can't we start some kind of program for BITNET that honors people who build useful tools for network users? (Yes, I'd certainly enter such a contest; I'm not *that* self-effacing. :-) Anyway, it's time to climb back down off my soapbox and get some work done. Richard
ACC00RRB@UNCCVM.BITNET (Robert R. Blackmun) (02/10/90)
Richard's comments strike a familiar chord -- I've suggested for some time that the best solution to the "volunteer vs. central staff" issue would be for CREN to use some of its surplus income or reserves to fund development projects by member universities. This would mean, for example, that Princeton or Rice or whatever campus received such a grant would be responsible for the development and maintenance, rather than relying on the "goodwill" of those institutions and their staff members, as we've done for many years. Unless expenses of operating Bitnic have increased dramatically as the result of the move to Washington or the merger (which were not projected in the merger documents), there should continue to be money to support such activities, especially if the members can agree on some way to decide what is *important* and how it is to be done.
HABERNOL@TUBVM.CS.TU-BERLIN.DE (Thomas Habernoll) (02/11/90)
>> However, like >>LISTSERV and NETSERV, NETNEWS does not seem to encourage imitators. >>There is no specifications document that would allow enterprising >>programmers on other systems to develop compatible programs. >Sorry, but here I disagree totally. There is a specifications document, >and it's RFC's 977 and 1036. Taken together, they should describe enough >to allow someone who wanted to write a NETNEWs-like beast for their >environment to create something which could communicate with the rest of >the Usenet world. Nope. Maybe the RFC's _should_ describe enough, but they _don't_. You can't write a Netnews system from scratch by only looking at the RFC. For the nitty gritty details you have to look how other systems are doing the work (and even then there are still enough controversy parts). This is not said to diminish the worth of Netnews, I'm preaching Netnews for years now. And even a weak RFC is more than we have for other critical network servers. And Listserv? Well, feel free to design, implement, and document! a better Listserv. Nobody would complain. But make sure that it provides such an effective transport mechanism as the current Listerv is doing. This is for most users the invisible part (contrary to mailing lists and file server functions), but it's the most important one in my opinion. Not just for mail/news, but for the distribution of software, too. There are _large_ software packages that can be sent to 10, 20, or even 100+ sites by Listserv's DISTribute mechanism while putting no more load on many links than a single copy would do. If this only wouldn't depend so much on an underlying NJE network ... Thomas