Joe Zeff posted on Mon, 04 Jul 2011 14:26:27 -0700 as excerpted: > On 07/04/2011 02:06 PM, Beartooth wrote: >> And how will the GNKSA, ossified or not, and New Pan's take on the >> GNKSA, affect things like the prestige of Gmane? > > I gather that the maintainer would be willing to update the GNKSA if we > were to come up with reasonable and well-reasoned suggestions.
That's interesting, as from the reply as mentioned in the other thread, I gathered that he saw it as primarily historical, and wasn't really interested in updating it, much as one (well, most "ones") wouldn't really be interested in "updating" something like the Roman Coliseum. (Restoring is a different matter entirely, perhaps the digital analogy would be more like ensuring proper archiving on the way-back machine, etc, not revising it.) My fear, and I readily admit it reflects my potential status as a USENET "old codger", is that the GNKSA was one of the more authoritative references encouraging such practices as replying under the quotes, discouraging multi-page quotes with only a single line response, etc, and that busting it in the one respect we're considering here will effectively "bust the dam" in regard to all the others, as well. So in practice, I see most of the GNKSA recommendations as still valid in general, tho perhaps a bit of tweaking would be fine. (Actual point-by- point analysis would come as part of my digesting the implications of this whole thing, something that I'm not mentally prepared to do ATM, but plan to within days or hours.) It's this connections thing that is most problematic, and that IMO, has certainly been problematic since the turn of the century at least. In fact, I'm not even sure it was ever valid, as written. A bit of history in that regard is that MSOE abused all sorts of at the time commonly-accepted-wisdom in its news behavior. It encouraged top- posting, it encouraged HTML (to be fair, so did Netscape at the time, and so does Thunderbird today, I /think/, tho I use something else so I'm not positive on that), it broke signatures by omitting the space after the -- (because quoted-printable used a terminating space before the CRLF as a line continuation character and the OE devs apparently didn't want to or perhaps never event tried to code around the implications for their sig parsing), it broke the still common 80-char fixed-width assumption and requirement for some users, due to use of implied format=flowed... probably some I'm missing... AND of particular interest in our context, it abused connections by opening many and then making very inefficient use of them. That's actually partly where the four connections per server limit originated for news specifically (tho it had roots in earlier proper netiquette connection limitations), because that is how many OE could open, and if the server allowed LESS than that, OE would spit out errors and fail to work right, thus greatly increasing support costs/hassles for whoever supported the server (ISP, NSP, volunteer running a server on a machine in his basement for a few text-groups-only...). But then OE would only actually properly *USE* only a maximum of two, one for a batched download if a user set that up first, and a second if a user then interactively clicked on a post at a time to download it, with the ability to click on several before the first one actually downloaded, thus creating a queue for the second connection. It was impossible for an OE user to actually use the four connections that OE needed to function correctly, to their fullest potential. One can see a reflection of this in the wording for the connections requirement, where it emphasizes using connections EFFICIENTLY as well as only establishing four, maximum. But certainly by the intro of Windows 98, which is when OE really got popular as it then shipped with the OS, any major news server had a server-side limit on the number of connections (at least, if they didn't verify user via login and charge by volume). As a practical matter they had to, because most servers capped bandwidth per connection at the time, and users quickly figured out that more connections got around the cap, up to any limit the server imposed, so the server pretty much /had/ to impose a connection limit. Plus, there were certainly script-kiddies around by then, that would, given the chance, open hundreds of connections and do little with them, just to DoS the server to death. So the 4-connection-limit was IMO a bit of an anachronism even in the late 90s, perhaps by the time it was introduced, which was certainly after version 1.2 (January, 1995) which doesn't mention the word "connections" at all. (Link courtesy of Wikipedia's GNKSA article.) http://thecia.net/users/rnewman/Good_Netkeeping_Seal And it's certainly an anachronism now. If a new version of GNKSA is to be written, I'd say that instead of setting a connections max limit, it should recommend two things (SHOULD/recommend or MUST/require could be debated, I left it at the less strict SHOULD/recommend): 1) That a newsreader SHOULD allow the user to configure the number of connections independently per server, if it allows for more than a single connection (per server) at all. 2) That a newsreader SHOULD try to make the most efficient use of the configured connections possible. IOW, none of this opening one connection only to update the newsgroups list and/or to see what the high- and-low-water article numbers are, then leaving it idle, that was apparently the sole thing the that MSOE did with one of its connections. If a user has downloads or uploads queued and has less connections currently actively sending/receiving data than the user has configured, then the client should attempt to use existing or open new connections to the user configured limit and make use of them for the queued jobs. A third one could be debated, too, tying into the current requirement 3) The pre-configuration default should be one/two/four connections per server. (Four could be debated but it shouldn't be more than that. A user could configure more if they wished. AFAIK some servers only allow two, tho that was far more common before MSOE for the reasons explained above, so two could be argued to be the more conservative and better default; I'm not aware of any public servers still making only a single connection per IP available, but they may be out there.) I don't believe a cap on the maximum number of connections is needed, because local application and machine resources will limit that to some degree, and anyone deliberately writing attach software or the like, the only reason I can think of to limit it beyond that, isn't going to be phased by such a recommendation/requirement anyway. In general, it's a server-side policy issue that the client shouldn't need to deal with, except to allow the user to configure as many connections as the user wishes or the server might offer. Meanwhile, I can mention that the http://gnksa.org home page mentions two mailing lists, gnksa-announce and gnksa-workers (just checked gmane, neither is carried there, at least with gnksa in the name, but gmane's head guy, Lars I. (IIRC a Norwegian name I'd have to copy/paste to get right), wrote something about news that favorably mentioned gnksa, that I found a link to somewhere, so he at least knows about it, I think I'll post a question to gmane.discuss to see if he has any suggestions). Joe, as you've kindly volunteered to be a liaison, perhaps you could look into that and see if those lists are still active at all (it would have been nice if I could have simply checked gmane, but...), with the idea of posting a question to see if anyone still subscribed may be interested in a revision discussion (seems I'm adapting to the idea of revising it, already! =:^). If there's any useful replies to such a question at all, the revision discussion should probably be moved to that list. But if there's nothing... here is probably as good a place as any. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman _______________________________________________ Pan-users mailing list Pan-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-users
