💾 Archived View for rawtext.club › ~sloum › geminilist › 002396.gmi captured on 2020-09-24 at 03:08:56. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Kevin Sangeelee kevin at susa.net
Fri Aug 14 14:26:26 BST 2020
- - - - - - - - - - - - - - - - - - -
Hi,
I think you're absolutely right that the scope of the web (or morespecifically, the web browser) has grown to the point that it mightsoon be impractical to make use of it without Google's tech (and youonly need to look at Android to see how that will play out, and Appleare little better). On the other hand, I don't think Gemini is theplace to address this; as I see it, Gemini stands on its own, with itsown purpose, which does happen to align with the original purpose ofthe web, and is perhaps why it seems the obvious to modify in the waysyou suggest (similar types of ideas crossed my mind too).
I personally think that the way to revive the web is to run HTTP on adifferent port so that content can be identified as separate from thecurrent web, and where this implies a reduced level of functionality(e.g. content that can be rendered by Kristall, or Dillo, or Lynx,etc.). I've put a lighttpd server on port 1993 of my Gemini server,though I've had no reason to use it yet - I'm free to *not* use anyweb features I don't want to. :-)
Well done on getting your C client running, if you're sharing thecode, I'd love to check it out!
Kevingemini://gemini.susa.net/
On Fri, 14 Aug 2020 at 09:59, /dev/urandom <dev.urandom at posteo.org> wrote:
Hello everyone,
The recent news about the layoffs at Mozilla have left me wondering as
to whether the modern web has become too complex. I've heard people
discuss the Gemini protocol as a simplified alternative that is way
easier to work with. After checking it out (and even trying to write a
small experimental client in C, which thanks to libtls, ended up way
easier than I thought), it seems to be a really promising idea.
I was thinking about an idea similar to Gemini that could work as a
protocol for not just websites, but also simple and functional web
applications as well that could, to a reasonable extent, look and work
well on lots of different devices (desktops, smartphones, feature
phones, text-mode interfaces). After seeing how the Gemini protocol
works, it seems to me that a lot of these ideas could be implemented in
a backwards-compatible way or with minimal modifications to the
protocol.
1. Basic form inputs / "widgets"
In addition to an "INPUT" response that only requests a line of text and
returns the question as a single line in the <META> field, some sort of
"extended input" could be useful. It could still be restricted to a
single query, but it could provide software-interpretable hints as to
what kind of input is preferable.
For example, a "check" input could provide a numbered list of options
and then ask the user to submit a query consisting a list of the
numbered items the user wants to select (or 0 if none). A more advanced
client program would then display the entire request as a series of
checkboxes or switches that the user can toggle. A "radio" or "button"
input could demand a single number, and the client would display the
items as a list of radio switches or buttons, of which only one can be
selected.
(I can imagine the description of the inputs either being part of the
<META> field, part of the previous page's text or maybe an "extended
input" could have its own response body that they're written in.)
Or a "date" input could say that it expects a date in the YYYY-MM-DD
format, but an advanced client could provide the user with a date picker
instead.
Either way, the general idea is that a simple client could just ask the
user to write the query as a line of text.
2. Continuous connections
A user might want to not just give commands to a service, but also to
expect it to provide a continuous stream of information over a long
term. Most modern web pages use scripting to accomplish something like
that (and most web-browsers wait for a page to finish loading before
displaying it), but a minimal version of this seems achievable without
it.
An additional response type (say, "21 SUCCESS WITH CONTINUOUS RESPONSE")
or mime-type (say, "text/gemini-continuous") would indicate that the
server will not give the entire response at once and then immediately
close the connection, but instead the connection will continue for a
long time, and instead of waiting for the entire text to be received,
the client should look for whenever a complete line arrives and print
that line.
The client could then use that connection to receive updates on the
request, until either the client or the server actually decides to close
the connection or it gets closed by some other means.
3. Append mode
This is just a little extra feature, but the idea is that a page
(probably also via mime-type, like "text/gemini-append", or an
additional parameter, like "text/gemini; append") could indicate that
its contents should, if possible, be added at the end of the previous
page, rather than replacing it entirely.
---
I would like to hear your opinions as to whether these ideas could, or
should, be added to the Gemini protocol, and in which specific ways if
so. Thank you all very much.