Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.infosystems.gemini > #552

Responses to some criticisms and how I am doing differently

Show all headers | View raw

I have looked at various criticisms of Gemini, and I have some of my own,
although I also think it does some good things. I have also looked at the
Spartan protocol, which is also good. Below, I quote various sources. I
will also reference my own idea of the alternative protocol, which I have
posted to this newsgroup (although there may be changes to the file since
I have posted it; you can download the latest version from the link
provided in my message (currently HTTP only, unfortunately)).

(Of course there are more criticisms but for now I just wrote what is below.)

> The web has become much more than a protocol for reading documents:
> controls that communicate both ways with the server so that they can be
> also updated in real time is a really useful aspect that won't make them go
> away anytime soon. I rather wonder if the browser is the best interface for
> that, or if html is the best protocol for that use.

I think HTTP and HTML are certainly not the best protocol for that, and
neither is Gemini nor my own one; there are others, e.g. IRC for fast chat
and Telnet for interactive use.

(However, Telnet doesn't have separate URL paths to access different
programs (and cannot transmit the host name); you must use different port
numbers, different IP addresses, or make a menu for the user to select one.
Some other protocols are also limited, and sometimes you might want to make
a different one but still use URLs. For this reason, my own protocol design
has the "I" subprotocol for this purpose.)

> Having links only on their own lines rather than part of text is really a drag

Links as part of text is not as good for being printed out on a paper.

(I have considered in my own format, to have a very restrictive kind of
inline links, although I have decided against it, for simplicity. What I
considered was that the link must be to another part of the same document
and that you cannot specify the text of the link (the client must decide
somehow, e.g. if it is printed out, as "page <number>" or "section
<number>" or similar, or if on screen, as a button that can be clicked).)

> No way to indicate basic formatting in-line in text, such as bold,
> emphasis, underline or code.

In my own design I have decided to have four (and they cannot be combined):
normal, strong, emphasis, fixpitch. Clients are allowed to ignore them,
except that "fixpitch" MUST use fixpitch fonts (although it is OK if all
text uses fixpitch fonts, in which case no special handling is needed).

The exact display of these styles is up to the client (and may be
configurable by the user).

> No way to specify syntax highlighting

This seems to me it is probably unimportant. (I am not entirely sure.)
(Adding it would make it more complicated anyways, probably.)

> No tabular data without resorting to hacks like preformatted blocks

I had considered tabular data in my format, but decided against it for
simplicity. Instead, you can link to another file with the data. (I wanted
to make a simple format that can be used for tabular data; CSV has a few
problems, but maybe TSV will be good.)

(Alternatively, I might change my mind about inline tabular data in future,
perhaps with some discussions about it before being done. However, a
separate file has some advantages; see below.)

> Readable preformatted text cannot be differentiated from artistic content
> like ASCII art, affecting accessibility

It is a valid concern, although results in some complexity.

> No inline images, diagrams, mathematics

I don't want inline images, though. (Nevertheless, it might be helpful for
printed out documents; but even then, you might not have a colour printer.)

I think that to clean the view, and to reduce bandwidth requirement, it is
better to not have inline images; the user must deliberately select them if
they want to view them.

For diagrams (of which there are many different kinds, so it is not simple)
and mathematics, that is a separate issue, but that would still result in
complication, so might be better to be avoided.

> No way to submit long-form content, like a multi-paragraph comment on a blog

For discussions, I think that NNTP would be better anyways, so I think this is
not a very good criticism. However, there are uses where it would be useful to
send using the protocol, such as a wiki, and I have included the "S" subprotocol
in my own specification, for this purpose.

Spartan also has the way to send data, in case you like that.

> No way for a server to indicate the size of a resource until it's all downloaded

This is my issue with Gemini too; I also don't like this feature of Gemini. So,
in my own I allow an optional way to specify the size of a resource. (I also
included range requests; implementation is optional.)

> To repeat, the existence of all these weaknesses is not a failure of
> Gemini. It was never intended to do those things. The challenge for someone
> who is suitably bored or innovative is to look at lists like these, expand
> them a bit, and work out how we could get the results we want without it
> inevitably snowballing into the madness that is arbitrary code execution in
> our browsers, people painting pictures with CSS, WASM, Web Bluetooth, and
> all the rest of it. There is a gaping chasm between Gemini and the modern
> web where something like this could be created.

I agree and am trying to do it (see my other message).

> The reduced complexity however also makes it less visually pleasing to
> users and by taking shortcuts in the protocol, it risks adding complexities
> elsewhere instead.

"Less visually pleasing" is not a problem. Clients can add styles (possibly
subject to user configuration) to use colours, fonts, etc, that the user will
desire; the document need not specify styles (which I think is undesirable
anyways; it is better for doing by the client by the user settings).

However, "risks adding complexities elsewhere instead" is a valid concern.

> There are multiple problems with doing TOFU [...]

I dislike TOFU also. I also think that mandatory TLS is also a problem.

> By insisting on passing on the entire URL in the requests, it is
> primarily a way to solve name based virtual hosting, but it is also easy
> for a Gemini server to act as a proxy for other servers. On purpose. [...]
> Since Gemini is (supposed to be) end-to-end TLS, proxying requests to
> another server is not actually possible while also maintaining security.

Passing the entire URL is good for name based virtual hosting.

Proxying is not mandatory anyways. Of course that is the issue with the
security, but then you would not use it if you need to be secure.

> The spec then goes on to explain that the URL needs be UTF-8 encoded when
sent over the wire, which I find peculiar because a normal RFC 3986 URL is
just a set of plain octets.

I agree that this is a problem. There is no reason for this. The URL should
be ASCII (which is what Spartan says, so it is an improvement).

They say that maybe this is only true of the host name. Well, that would
at least be meaningful, but I still think that it is unnecessary and is
also a bad idea anyways; ASCII only is still better (you can still specify
any host name in purely ASCII, so such a thing will still work).

> There is nothing written about how a client should deal with the existing
> query part in [the text input] situation.

This is why I specified, in my protocol design, that the server MUST NOT
use the 1x response in this case. (If it does anyways, then the result
is unspecified.)

> The protocol enforces closing the connection after every response,
> forcibly making connection reuse impossible. This is terrible for
> performance if you ever want to get more than one resource off a server.

Using a new connection each time is much simpler, though, so it does have
that advantage.

The Gemini file format doesn't load multiple resources at the same time,
so it is not needed to load multiple resources at the same time.

> [Gemini] comes with significant trade-offs for the author, however.
> Compared to standard vanilla HTML4, there are no inline links, no provision
> for media other than text on a page, and the styling of the content is left
> to the client.

I have mentioned reasons above why I believe that these trade-offs are
desirable, however. I agree with Gemini here, and disagree with the criticism.

> I used to be a Gemini enthusiast before it hit me: if this is really a
> content-focused markup language, where the client gets to decide how to
> present the content, then why must I used ASCII art (or worse, a separate
> CSV file) to display an inline table? ASCII tables are terrible for screens
> that are either short or wide, don't have line wrapping, don't have column
> alignment, and have absolutely abysmal accessibility.

It is a valid concern. However, I think that a separate CSV file is better
than using ASCII art rather than worse, although I can also understand the
opposing point of view; it is also valid.

> What if we can re-introduce the plugin system in a safe way? Can a
> hypothetical FireChrome browser VM automatically download a MusicXML
> snippet rendering plugin from my site when a user visits it and ask the
> user if they want to run it (license: GPL, signed by dmbaturin's key, wants
> access to: current page). That's something I'd be happy to use, something
> that gives me and visitors more opportunities, not less.

This is an interesting idea, and I have considered something like this, too.
(Actually, I considered even a "Interpreter:" header for HTTP, which would
allow web browsers to load file formats they do not recognize.) 

However, there are still many concerns. For my protocol design, if such a
thing is wanted (which should be an optional feature anyways, and authors
should use fallbacks where possible), possibly a sandboxed uxn/varvara (or
something similar) could be used, only having read-only access to the
current file. It could be according to the specific file format, so that if
you already have a viewer for that file format, then you can use the
existing viewer; in some cases there may also be a text fallback, and/or
graphical fallback; e.g. music being displayed as MML code or as a picture
or audio file.

I agree that it should not run the program automatically (it must always
ask the user first), but with the sandboxing, the other stuff mentioned in
the quotation may be unnecessary. It only needs access to the file being
displayed (which might even be a local file), not any others. It does not
put anything inline into other documents.

(It could also work with picture formats, e.g. by converting them into
streaming farbfeld format.)

However, allowing client software to implement it themself if desired, as
well as new user interface features for existing ones, is much better than
using JavaScripts in HTML to implement them, and then it is difficult for
the user to add their own. But, instead having the file formats for data,
etc, you can easily do it, e.g. one client program might include the
feature to plot the data on a graph, or to sort or filter the data, or for
the user to enter calculations for aggregate statistics, etc.

> Scientists don't need tables implemented in their markup. They need
> tables inside linked files that readers can actually use in data analysis
> without having to learn yet another complex technology. The browser could
> render linked CSV or SQLite files in a nice table widget for instance and
> people interested in the data could open it up in R and not have to mess
> around with parsing XML.

I agree with the first sentence especially. I do think it would be better
than how it works in the usual HTML.

> Gemini also has some issues with inline language changes if I remember
> correctly, which has some accessibility implications.

This is true; Gemini does not support this. (It also prevents documents
from being displayed correctly in some cases, due to using Unicode.)

> When weighed against some of the other proposals people have made to
> "simplify" the modern web (Amp, PDFs, Canvas, etc...), Gemini is noticeably
> better and noticeably more accessible, and actually has a real community of
> people using it.

I agree; Gemini is much better than the other stuff listed there, which is
just as messy and complicated and problems.

> The automatic hyphenation algorithm used in browsers is also visibly
> inferior to the one used in LaTeX.

This is a problem mainly because WWW is too complicated; if it wasn't, then
it would easily be fixable, of course. It has nothing to do with Gemini.

However, TeX also allows hyphenation exceptions, and you can specify the
hyphenation rules for each languages.

> So it's borderline useless for all but the simplest use cases, and even
> there it does a very subpar job. I'd like to have an inline image every now
> and then, or organize things in some multi-column layouts or the like, or a
> table.

I think inline images and multi-column layouts are undesirable. Tables may be
useful for data, but should not be used for layout.

Gemini isn't useless. Even, many files are just plain text files, and they
are not useless, either.

-- 
Don't laugh at the moon when it is day time in France.

Back to comp.infosystems.gemini | Previous | Next | Find similar

Thread

Responses to some criticisms and how I am doing differently news@zzo38computer.org.invalid - 2023-12-26 21:17 -0800

csiph-web