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