💾 Archived View for rawtext.club › ~sloum › geminilist › 002399.gmi captured on 2020-10-31 at 14:31:10. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Matilde Park matilde.park at sunshinegardens.org
Fri Aug 14 15:28:33 BST 2020
- - - - - - - - - - - - - - - - - - -
Was responding to OP, sorry. (Getting a handle on mailing lists.)
On Aug 14, 2020, at 10:26 AM, Kevin Sangeelee <kevin at susa.net> wrote:
I'm not sure if you intended to reply to me, but if so, I think you
are indeed mistaken. To be clear, I get Gemini, its simplicity and
immediacy are everything. I'd be happy if it stayed exactly as it is.
Kevin
On Fri, 14 Aug 2020 at 14:35, Matilde Park
<matilde.park at sunshinegardens.org> wrote:
I think this proposal misunderstands the utility of the Gemini protocol, though I may myself be mistaken.
The web itself shouldn’t have become a widget library, or a set of applications. The DOM is a poor replacement for something like GTK, et al., and HTML/JS/CSS has come pretty far in approximating it to an operating system by punting an operating system level of complexity to the client — thus web browsers are unmaintainable by anyone other than corporations who can build an operating system to a specification.
In this regard, I think protocols like gemini:// or gopher:// aren’t meant to *supplant* the web, but have a specialised purpose. There can be a very small, human scale specification. Let HTTP do what it’s become specialised to do; and in our own projects, abandon it. In doing so, you can avoid the incentives that brought clearnet where it is now.
On Aug 14, 2020, at 9:26 AM, Kevin Sangeelee <kevin at susa.net> wrote:
Hi,
I think you're absolutely right that the scope of the web (or more
specifically, the web browser) has grown to the point that it might
soon be impractical to make use of it without Google's tech (and you
only need to look at Android to see how that will play out, and Apple
are little better). On the other hand, I don't think Gemini is the
place to address this; as I see it, Gemini stands on its own, with its
own purpose, which does happen to align with the original purpose of
the web, and is perhaps why it seems the obvious to modify in the ways
you suggest (similar types of ideas crossed my mind too).
I personally think that the way to revive the web is to run HTTP on a
different port so that content can be identified as separate from the
current 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 any
web features I don't want to. :-)
Well done on getting your C client running, if you're sharing the
code, I'd love to check it out!
Kevin
gemini://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.