someoddRequest for comment: vision for content publishing on Gopher.
If Gopher had won, we wouldn't be using web-metaphors.
@screwlisp I'd love your input.
screwlisp@someodd Aside, something I am bitingly aware of is that I have never read Nelson's computer lib or literary machines - however, I have at length spoken with KMP about Kent's own works (Kent read literary machines).
Something that occurred to me is that browsing gopher is like browsing a unix directory in contrast to anonymous ftp. This made me think about using find(1)
find . -wholename "./*.*" -exec cp {} '{}.bkp' \;
However, this would clash with bartleby's special files. Thoughts follow.
/
@someodd I definitely like your idea of a library catalog of a gopher directory structure. But I would leave the low level unix directory structure alone, and make a separate, high level gophermap hierarchy that better reflects normal needs than the original filesystem hierarchy.
I guess the Dewey Decimal system was something you stuck onto books and reshelved them accordingly. Fortunately for gopher, you can specify the hyperbook, from multiple places and not reshelve it.
/
@someodd Two points for the un-gopher-knowledgeable.
gopher+ was proposed https://github.com/jgoerzen/pygopherd/blob/master/doc/standards/Gopher%2B.txt . Where gopher specified a gophermap put a CRLF, gopher+ allowed a <tab>+CRLF to indicate gopher+.
Gopher+ queries are like
specifier<tab>$+metadata-I-want-one+metadata-I-want-two+..<CRLF>
for some compulsory but also arbitrary metadata "blocks" or just $ for 'all of them'.
vs gopher's
specifier<CRLF>
#gopher
/
@someodd also to control whether files/subdirectories in a gopher unix directory are served, many gopher servers use the unix permissions (viz inode(7) ).
So what I would like to see, sorry that it is very different:
bartleby generates a gopher+ library catalog fresh directory tree, each directory with a generated gophermap whose items refer into the unchanged original gopher directory.
Say I have
foo.txt
~permission g+r
with the companion gopher+ metadata file:
foo.SUMMARY
~permission g-r
/
@someodd
Then when the user (who has permission to read foo.SUMMARY, which is u+r) runs bartleby(1), foo.SUMMARY gets hoovered up into the generated gopher+ library catalog and is put as a +SUMMARY gopher+ metadatablock, e.g. accessed by the request (item specifier):
foo.txt<TAB>$+SUMMARY<CRLF>
where foo can still be specified as gopher:classic by:
foo.txt<CRLF>
/
@someodd This also implies *not* adding file header lines to some files: Instead, just have gopher+ metadata with those things you want (I think +DATE is already compulsory).
One more thing about the errors. I think "Error: please handwrite your server into some.yaml file" should instead let the user pick from the likely server candidates or optionally enter it now and retry / or abort and fix it themselves.
Similarly, missing DATE should offer to choose either now or the file's date.