💾 Archived View for gemi.dev › gemini-mailing-list › 000323.gmi captured on 2024-03-21 at 17:23:05. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
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.
Hello and welcome!
On Fri, 2020-08-14 at 11:59 +0300, /dev/urandom wrote:
> 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.
It's interesting... but also a bit of a feature creep. My suspicion
would be that all of this could be handled by simple string input and
validation (your age, your zip code, your preferred choice from a
menu), or by using links to provide alternatives... I do wonder what
you have in mind though. I'd say if the goal is to write web apps,
perhaps Gemini is not the right way to do it. And every extension makes
it a bit more complicated and at the end people can't implement it in a
day. We'd be repeating all the iterations of HTTP and HTML, no?
> 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.
I think you'll find a discussion of this in the archives. Look for the
thread "Reopening: Stream status code". I think the key message is this
one:
gemini://gemi.dev/gemini-mailing-list/messages/002269.gmi
"This is mainly just an issue of what to do about timeouts, right? If
you don't have any timeout at all, streamed content works fine, but
buggy/overloaded servers hang the client, and that's bad. If you have
a fixed timeout of 5 seconds, some streaming applications (like the
chat example mozz has done) break."
> 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 think if you read the discussions regarding streaming, you'll see
that if the server doesn't hang up, and if clients don't implement
timeouts, all of this naturally just happens.
> 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.
Sorry to be a cold blanket here, but my answer is No to all of the
ideas. Instead, with respect to your ideas, let's focus on these two
points:
1. Clients without timeouts with an appropriate UI to help users
interpret what they are seeing.
2. Websites ("applications") with appropriate user interfaces such that
we don't need structured input.
I think it's doable, but it isn't as simple as it seems at first sight.
Cheers
Alex
On Fri, 14 Aug 2020 12:50:57 +0200
Alex Schroeder <alex at gnu.org> wrote:
> It's interesting... but also a bit of a feature creep. My suspicion
> would be that all of this could be handled by simple string input and
> validation (your age, your zip code, your preferred choice from a
> menu), or by using links to provide alternatives... I do wonder what
> you have in mind though. I'd say if the goal is to write web apps,
> perhaps Gemini is not the right way to do it. And every extension makes
> it a bit more complicated and at the end people can't implement it in a
> day. We'd be repeating all the iterations of HTTP and HTML, no?
I understand. My intention was that, for a basic client, the input
would still work in the exact same way. You get a basic string, enter
something, it gets added as a query, and the server returns either a
2x or a 59. But the more advanced clients could provide an
alternate input method to make it easier for the user.
And, of course, repeating the mistakes of HTTP and HTML is something I
want to avoid as much as you.
> I think you'll find a discussion of this in the archives. Look for the
> thread "Reopening: Stream status code". I think the key message is this
> one:
> gemini://gemi.dev/gemini-mailing-list/messages/002269.gmi
> "This is mainly just an issue of what to do about timeouts, right? If
> you don't have any timeout at all, streamed content works fine, but
> buggy/overloaded servers hang the client, and that's bad. If you have
> a fixed timeout of 5 seconds, some streaming applications (like the
> chat example mozz has done) break."
I guess that ideally, any client would use threads or some other
mechanism to allow for the user to read the already-loaded parts of a
page while it's being loaded, while indicating that the page is
"incomplete" in some way in the user interface.
Then it wouldn't be necessary to specifically signal server-side
whether or not the page is streamed or loaded as a single piece.
> I think if you read the discussions regarding streaming, you'll see
> that if the server doesn't hang up, and if clients don't implement
> timeouts, all of this naturally just happens.
The third suggestion (appendable pages) was actually unrelated to
streaming. I was instead suggesting it as a way for applications to
send small messages in response to requests in a way that doesn't
require the server to re-send the original page every time.
> Sorry to be a cold blanket here, but my answer is No to all of the
> ideas. Instead, with respect to your ideas, let's focus on these two
> points:
>
> 1. Clients without timeouts with an appropriate UI to help users
> interpret what they are seeing.
>
> 2. Websites ("applications") with appropriate user interfaces such that
> we don't need structured input.
>
> I think it's doable, but it isn't as simple as it seems at first sight.
It's all okay. I understand and appreciate your responses anyway.
> Cheers
> Alex
Thanks!
~ /dev/urandom
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.
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.
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. >
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. >>
Ha, mailing lists have always filled me with dread - unretractable faux pas being central to my worries! On Fri, 14 Aug 2020 at 15:28, Matilde Park <matilde.park at sunshinegardens.org> wrote: > > 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. > >> >
An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200814/0988 2b9b/attachment-0001.htm>
On 8/14/20 4:59 AM, /dev/urandom wrote: > 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). Gemini has hard conceptual/technical boundaries which make it pretty unsuitable for building general purpose applications. And that is, of course, on purpose. I've thought for years that browsers should have entirely separate modes of operation: one presents content and the other is an application client. The user would have strict control over which mode was being used, so I could say that reddit.com can only do "displaying content" things, but gmail.com can do "application" things. But I like even more the idea of having separate clients (and protocols) for these purposes. I feel like Gemini "solves" the content mode. We still need the application mode. Universal distributed applications are incredibly useful and cool (and that use of the Web keeps me employed). But the Web _sucks_ for making applications. So, if I were to build the "Gemini of applications", I think I would take a hard look at two things:
Yeah, I think what we need is a system with using sandboxed WASI with some kind of file based GUI API. Apps would be run in a sandbox with a temporary folder and a size limited persistent folder. I think the name Gravity Runtime is good. On Tue, Aug 18, 2020, 2:51 PM Dave Gauer <dave at ratfactor.com> wrote: > On 8/14/20 4:59 AM, /dev/urandom wrote: > > 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). > > > Gemini has hard conceptual/technical boundaries which make it pretty > unsuitable for building general purpose applications. And that is, of > course, on purpose. > > I've thought for years that browsers should have entirely separate modes > of operation: one presents content and the other is an application > client. The user would have strict control over which mode was being > used, so I could say that reddit.com can only do "displaying content" > things, but gmail.com can do "application" things. > > But I like even more the idea of having separate clients (and protocols) > for these purposes. > > I feel like Gemini "solves" the content mode. > > We still need the application mode. Universal distributed applications > are incredibly useful and cool (and that use of the Web keeps me > employed). But the Web _sucks_ for making applications. > > So, if I were to build the "Gemini of applications", I think I would > take a hard look at two things: > > * WASM for execution > * Existing UI languages for layout > > https://en.wikipedia.org/wiki/WebAssembly > https://en.wikipedia.org/wiki/List_of_user_interface_markup_languages > > I like your abstract input examples. The client should be able to > determine the best way to present this to the user. Entering a date on > a desktop computer should not use the same UI as a touchscreen kiosk or > a voice-activated home assistant! Nor should the application developer > need to create these UIs from scratch each and every time. > > Hmm, now we just need a good name for a "Gemini of applications"... > > :-) > > > > 2. Continuous connections > > 3. Append mode > > #3 is intriguing. I suppose it's to allow the server to respond with > messages such as "I didn't understand 'asdfklj' as a date!" or provide > interactive feedback, such as a session with an Eliza-like chatbot or > > -Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20200821/85a7 00dc/attachment-0001.htm>
---
Previous Thread: [ANN] Fafi, a Racket-based client
Next Thread: Installing CAPCOM on FreeBSD 12.1 (need gusmobile)