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.
---
Previous in thread (4 of 11): 🗣️ Kevin Sangeelee (kevin (a) susa.net)
Next in thread (6 of 11): 🗣️ Kevin Sangeelee (kevin (a) susa.net)