Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!nntp.club.cc.cmu.edu!micro-heart-of-gold.mit.edu!bloom-beacon.mit.edu!bloom-beacon.mit.edu!panix!MIX!Blackbird From: billy@MIX.COM Newsgroups: comp.sys.mac.system Subject: Re: POP3 vs. IMAP Date: Wed, 7 May 2014 19:27:44 +0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Lines: 187 Message-ID: References: <5363472a$0$50666$c3e8da3$92d0a893@news.astraweb.com> NNTP-Posting-Host: panix5.panix.com X-Trace: reader2.panix.com 1399490864 3108 166.84.1.5 (7 May 2014 19:27:44 GMT) X-Complaints-To: abuse@panix.com NNTP-Posting-Date: Wed, 7 May 2014 19:27:44 +0000 (UTC) Xref: csiph.com comp.sys.mac.system:59179 Doc O'Leary writes: > No; don't just accept bad software design as a given. The *first* thing > I did when I started my newsreader to decouple the NNTP bits into their > own framework, and even in there I have the parts that care about > communicating with the server abstracted away from the core > functionality of dealing with messages. That is why I expect my reader > to be able to more easily support POP or IMAP (or just about anything > else that can be massaged into a message) in the future or, on the flip > side, re-use that NNTP framework for other apps or command line tools. > Your "Of course not" explains why things like curl lack support for news > or nntp URL schemes, and why Usenet continues to slide into obscurity. Huh? Daily traffic is steadily increasing, and has gone from about 3GB back when I worked on tin (ca 1994) to past 15TB(!) today. How do you get to "continues to slide into obscurity" from that? Perhaps you mean the loss of many of the better educated, more articulate, and wiser past participants, who've moved to private mailing lists, et al., due to the overwhelming moronity of so many newer users? Well, building a "better" newsreader is not going to solve that problem, at all. > Your casual negligence is embarrassing. I could offer the same observation about casual ignorance... And, there are already plenty of email user agents, and web browsers. Not to mention web sites. What value do you see in distributing, for example, web log content via Usenet? Or video, etc? Most of the 15TB daily traffic is material that'd far better served elsehwere, by the way. In spite of this, propagation is quite good, but as far as I know it's due to the generousity of many organizations hosting feeds that are not (directly, at least) generating enough revenue to cover their costs. If I want to follow a URL in a Usenet article, I can easily invoke a web browser. The site hosting it can pay for the resources necessary to deliver it (video, photos, etc). Works for me. > > Hmm. I thought C is self-documenting. More or less. Heh. > > It could be, if developers had half a clue. One look at the tin source > shows that nobody that apparently cares to make things easy for > outsiders to pick up. I mean, for goodness sake, would calling an > article more than "art" kill you? And that's hardly even the tip of the > tip of the *tip* of the iceberg. What - you don't like label names that are entriely adequate for anyone even casually familiar with the art? Geez. The stuff is write is in assembly language, and is fully commented, such that anyone familiar with the language can read and understand it. But, is it a tutorial for anyone else? Nope. Example - http://MIX.COM/KRTKM.MAC > > Better to me means it works, and works well. Particularly in the > > real world, where not everyone follows the RFCs/standards/etc. > > Yes, the battle cry of most mis-managed open software projects: It works > well . . . until it doesn't work at all. Look, like the OpenSSL coders, > need to take a step back and see what you've done with a fresh set of > eyes, and start making changes that make your past efforts more useful > to today's users and developers. Tin is just a newsreader. It's not a web browser, it's not an email user agent, nor is it anything else. It does allow one to invoke a web browser, and it does support some basic email functions (I can easily mail myself articles I want to save, for example). It works now, and will continue to work fine, even if it was not actively maintained. I think slrn's sources may be more instructive, at least more easily parsed by you. I haven't looked at them in a long time, but I am a heavy user of John Davis' text editor, and his coding style there is more like what you're expecting/hoping to find. > My experience with open source projects is that they won't do that, > which is why I find myself having to re-code things that should have > been taken care of decades ago. I mean, even your newsrc handling is > awful. I could have taken the time to figure out how to apply your > junky ol' code to what I want, or I could do what I ended up doing, and > essentially run the file through an NSScanner to construct an NSIndexSet > of read articles for each group. Tin pre-dates Next Step. > You have no equivalent higher-level concepts for parsing strings > or article ranges (which tin code calls bitmap sequences, for some > strange, non-self-documenting reason). That's only "works well" > by some 1980s definition of the phrase. What - I'd expect you know what a bitmap is.. Tin dates back to when RAM was not so freely available. > > They're character cell (text) terminal based newsreaders because > > Usenet is a text medium. > > As long as you believe that, your software will continue to slide into > irrelevance. In reality, Usenet is abstractly a CDN. It's a _text_ CDN, yes. > And the people who use it deserve to be more than a few characters > in a From: header. For example, what? > The truth is more likely that you *want* to keep newsreaders stuck in > the terminal because you're either unwilling or unable to envision a > better future for the technology. And what about all the other technologies, protocols, et cetera? Why do you what to put 10 kilos of stuff in a 5 kilo box, when there are so many 10 kilo boxes at hand, begging to be filled? > That's sad, and it's a shame that your efforts with tin will be lost > in time rather than having been something that future generations could > build on. See above. > > > Believe me, I would *love* to find some open source code for a > > > newsreader that looked like the developers knew they needed to package > > > it for other developers to read/use. If you can actually point me to > > > that, you'd be a hero-by-proxy. > > > > I'd like to, but I don't think it (yet..) exists. > > Which is why I've taken on the fool's errand of re-writing things > myself. If there's enough support, it'll be released as open source. > Given the state of Usenet these days, though, I'm not expecting to even > break even on my efforts. Nobody has ever gotten rich implimenting or maintaining Usenet. I can't speak for anyone else, but I do it for fun. And, once in a while, I am a bit better educated from it. > > Well.. There's a lot of info available in tin/slrn sources that'd > > be useful to anyone. > > Not nearly as much as you think. Speaking from experience, as an > outsider, the code is *at best* not useful and, at worst, exhibits signs > of deranged minds. I'm speaking about, in this particular case, dealing with various server quirks. You can read, and learn, or do it that hard way - write something and then deal with complaints and bug reports from your users when they enounter the same stuff. > Go ahead and try and talk your tin friends into getting them to factor > out a libnntp that can used, at the very least, to simply process Usenet > URLs. I'm just speculating, but I'd expect they'd say, "You're the one who wants it, so get busy and write it yourself." > Until that sort of thing is eagerly embraced, you should gravely doubt > the usefulness of tin source code in the future. Well..... If you can get the IETF and others involved to add what you want to the Usenet standards and best practices, I'm quite confident tin and slrn will follow. To their credit, tin's maintainers adhere to them extremely well. And I'd bet slrn does, too. > Again, I know that all reads as more hostile than intended. No problemo, I'm not taking it as hostile, at all... > Like I said, my experience with poorly run software development is that > the people involved aren't interested in fixing what's wrong, and so I > prefer not to get involved with their mutual back-patting sessions. I > just laugh and walk away from "brogrammers" who think committing code is > the most important thing in the world, yet the code they're cranking out > is all garbage that they think "works, and works well". ...but, I've got to say I think this is a rather distorted point of view. Billy Y.. -- sub #'9+1 ,r0 ; convert ascii byte add #9.+1 ,r0 ; to an integer bcc 20$ ; not a number