SoylentNews is people
SoylentNews
from the insert-oblig-caddyshack-reference dept.
For many people, the world wide web is synonymous with the Internet. While the HTTP protocol dominates the modern Internet, many protocols obsolete, obscure and well known make up the Internet.
One of the more stubborn protocols is Gopher. Introduced in 1991 (the same year as HTTP), Gopher, like the web, is document-centric.
By about 1990, information on the Internet was expanding rapidly enough that it needed more organization and a better search capability. In 1991 researchers at the University of Minnesota developed the Gopher protocol in an attempt to provide some of that organization. Gopher provides a hierarchical text-based menu system to organize the contents of a data repository (which eventually came to be called "gopherholes").
https://prgmr.com/blog/gopher/2018/08/23/gopher.html
(Score: 3, Interesting) by BsAtHome on Monday August 27 2018, @11:01AM (10 children)
Should SN not have a http-to-gopher-gateway? Could be a fun experiment to run news on gopher.
(Score: 3, Interesting) by Arik on Monday August 27 2018, @12:32PM (1 child)
So did you mean an nntp-to-gopher gateway then?
Might need to get the nntp part working first.
If laughter is the best medicine, who are the best doctors?
(Score: 5, Touché) by RamiK on Monday August 27 2018, @02:19PM
Asked and answered. [soylentnews.org]
compiling...
(Score: 0) by Anonymous Coward on Monday August 27 2018, @02:07PM
Add php support to gopher, allow adds being displayed and then youl get it running everywhere.
(Score: 2) by DannyB on Monday August 27 2018, @06:33PM (6 children)
Gopher clients are way lighter weight. I ran one on an early 90's Macintosh. A modern gopher client probably wouldn't need much more today.
First problem: Gopher doesn't do graphics. SN does, technically, use graphics.
Idea: Gopher support on SN. Then a browser to gopher gateway so that modern browsers could read SN.
Since you can run entire PC emulators in a modern browser, running Windows 95 [win95.ajf.me], it would be possible to use an old gopher client from that era to read SN.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Monday August 27 2018, @07:54PM
To illustrate how much lighter gopher clients are by example: My father went to a programming school in Python. For extra credit, he implemented a rudimentary gopher client. The whole thing was under 50 lines of code too.
(Score: 2) by dry on Tuesday August 28 2018, @01:22AM (4 children)
Gopher is quite capable of calling a graphics viewer and displaying graphics as well as any other program. This is how the OS/2 Gopher client (1994) worked and it worked quite well, basically using the OS associations to display whatever.
(Score: 2) by DannyB on Tuesday August 28 2018, @01:07PM (3 children)
It worked that way on the Mac too. But it had to commit the heresy of using (gasp!) a file extension to attempt to determine what program to launch to handle the content.
The classic Mac did not use file extensions, or pathnames, or drive letters. It had something that was sort of a forerunner of MIME type (but released in early 1984).
The problem with file extensions is that users might not name their files with file extensions, If they did, the user could easily change the extension. But they could not change the file's "type". They could see the file's type, but not change it. The file type was just another attribute of the file's directory entry if you did something like the 'ls' or 'dir' command (but there was no command line).
If you served a file with a gopher server on a Mac (or ftp server, etc) you typically had to be techie enough to know to name your files with extensions for the benefit of other systems. But why would granny save a file with an extension like ".jpg".
The lower I set my standards the more accomplishments I have.
(Score: 2) by dry on Tuesday August 28 2018, @03:05PM (2 children)
Yea, OS/2 was similar, saving the file type as an Extended Attribute (xttr) along with whatever program a data file was associated with, so one jpeg would open one program when double clicked and another jpeg could open a different program, and the association could be changed by right clicking and opening the settings (properties later). The main difference was that, starting out as a DOS replacement and continuing to happily run DOS or Win 3.1 programs meant that the extension was the fallback and users were used to using file extensions so when a program had no association, it usually had a relevant extension.
(Score: 2) by DannyB on Tuesday August 28 2018, @03:25PM (1 child)
Mac has two attributes of a directory entry: "type" and "creator". Type indicated how to interpret the bytes in (the data fork) of the file. Creator indicated what application to launch. Multiple apps might be able to read a JPEG. Double clicking one JPEG file would open it in Photoshop, but double clicking another JPEG file might open it in a Viewer app. This would not be surprising. The first JPEG file would have a "Photoshop Jpeg" icon, while the other JPEG file would have the "Viewer Jpeg" icon. The combination of type-creator determined the icon for a file. Each app which has a 'creator' value, furnishes a list of the types it can open along with an icon for that type, for this particular application.
Another difference is Mac did not have drive letters. It did not have pathnames. Nor file extensions. But a file could have more than just the "data" in it (the data fork). A file could also have a database of "resources" that could be retrieved by resource type and resource id. So I could fetch 'ICON' 128 from a file's resources. Or fetch 'TEXT' 199, or 'CODE' 120, etc. An app had no data fork (until PowerPC) and only had resources. The code segments of an app were resources, starting from CODE id zero. Developers could make up arbitrary four character resource types, and there was sort of a central registry. This was all released in 1984.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Thursday September 20 2018, @03:10PM
Macintosh absolutely had pathnames. They used a colon for a separator instead of a slash, and started with the name of the HD (e.g., "Macintosh HD:System Folder:Finder"). They were used internally, not frequently visible to the user, but they were there.