💾 Archived View for gemini.bunburya.eu › newsgroups › gemini › messages › 1646331056.bystand@zzo38co… captured on 2024-02-05 at 09:49:42. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2022-04-28)
-=-=-=-=-=-=-
From: news@zzo38computer.org.invalid
Subject: Re: teletext-ish pages?
Date: Thu, 03 Mar 2022 11:17:04 -0800
Message-ID: <1646331056.bystand@zzo38computer.org>
<joe@example.invalid> wrote:
Having tools that generate gemini pages, instead of HTML, from code the
way DoxyGen does seems like it would have been a major boost for gemini,
but the SSL requirement really breaks a lot of stuff.
I agree that TLS should not be mandatory; it should be optional. I had
previously proposed a "insecure-gemini" protocol. Its specification is:
"gemini" and "insecure-gemini" the same in the request text.
client certificate to be accessed, then it must issue a 3x response which
redirects to the secure version of the Gemini protocol.
stunnel does not have this capability, making this difficult to implement.
However, the protocol does not seem to be ambiguous, so it would seem to
me that it should be possible somehow.
bytes with the high bit set are treated the same as the corresponding
percent encodings by the server. If the server's domain name uses any
non-ASCII characters, then it should accept both the Punycode and UTF-8
representations of the domain name. (This retains compatibility with the
existing protocol, but allows for non-Unicode filenames too. A client
which uses Unicode text input will require that these names are percent
encoded if they are not valid UTF-8.)
MUST be represented using only ASCII characters, otherwise the result
of trying to follow that link is undefined. (Non-ASCII characters are
allowed if they are percent-encoded or if the document is UTF-8.)
SNI, it assumes whatever is appropriate, defaulting to the domain name
given in the request if that name is appropriate.
optional parameter in the <META> line to give the length of the response
in decimal (if it is known; if not, then it can be omitted). (This also
allows download progress to be displayed.) (Although, maybe this is too
difficult to fit into the existing protocol.)
I'd also like to see support for color.
I disagree. The colours should not be defined by the document. (If you
need coloured ANSI art, you could either include a telnet link or you
could serve a file of a different file format, I suppose.)
Ascii (well, unicode really) art with unicode can be very, very
impressive and quite artistic. If it were possible to add color, this
would totally rock. (it would also really suck for blind people, but you
could, and should, wrap it in ``` anyway. Blind readers could skip that)
Actually, I think that Unicode is very bad for a lot of things, and would
rather not use it. It is especially bad for "ASCII art"; some character
widths may be ambiguous, or not ambiguous but wrong for your application,
or mismatch by fonts, not lining up or other character properties wrong,
other ambiguity or non-ambiguity which does not match (e.g. in the PC
character set, one character can be either Greek or German), and then
tere is han unification, complex scripts, etc. This is a huge mess.
(However, the "lang" parameter can mitigate the problem with the han
unification, sometimes, at least. Not always.)
Adding colours can be done in a separate file, perhaps.
Petscii is still a thing in some circles. There are ascii art contests
that still take place. To be truly impressive, they need color support.
This is true, but the Commodore 64 colours are not the same as the ANSI
colours, though.
If you support unicode, (via the terminal) this shouldn't be that much
harder. The terminal does all the work. The challenge would be malware
that sends escape codes to bugger up the screen. (even then, the worst
that could happen is you need to do a screen reset. Hardly a big deal)
I am not sure what is the worse that can happen, actually. Messed up
screen is not necessarily the only possibility.
I've never used teletext, I've read about it though. There are quite a
few people who miss it. They sound a lot like gopher users who prefer
the simple interface.
Neither have I, but I read about it.
Teletext was an old protocol for television sets that allowed you to
view news pages, weather, etc.. in a semi-textual format.
There is also Viewdata, which I think is similar. There are some Viewdata
services existing that you can access over the internet, and you can use
a Viwedata client to access it. It is a interactive protocol (similar to
telnet), unlike static pages that were previously used in television.
I could easily see designing a teletext type of client for gemini but
color is important. Teletext DID have graphics, implemented via a kind
of escape code into an alternate character set of blocky characters, not
unlike commodore graphics. Unicode could probably do this too.
I argued above that Unicode shouldn't do it.
SSL is a deal breaker
---------------------
Imagine what a flop UNIX would have been if 'grep', 'awk', 'sed'
required all their input to be encrypted.
Unix was a big success in part because the commands don't actually care
where the input is coming from.
I agree; TLS should not be mandatory.
I mentioned above some ideas about "insecure-gemini" protocol.
--
Don't laugh at the moon when it is day time in France.
Parent:
teletext-ish pages? (by <joe@example.invalid> on Thu, 3 Mar 2022 06:49:40 -0000 (UTC))
Children:
Re: teletext-ish pages? (by <joe@example.invalid> on Fri, 4 Mar 2022 11:48:39 -0000 (UTC))