💾 Archived View for gemi.dev › gemini-mailing-list › 001066.gmi captured on 2024-06-16 at 15:35:17. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-12-28)
-=-=-=-=-=-=-
Dear Geminauts, I am pretty aware the specs are somehow frozen, but I entered in the Gemini space about six month hence I missed a lot of its evolution. Even though I have not been very prolific in terms of pages made on my capsule, basically for lack of time, I work and use it every day since the day I started. I hope you will give even for the late comers the opportunity to express their opinions! The daily use of Gemini, since being both author and reader, let me consider that it would be useful create an alternative flavor of the gemtext => link. I think that adding a secondary behavior will increase the ability for both author and reader to have more control on the way the content is delivered and accepted, also this idea looks toward the future where possibly more GUI client will be available. Today the specs define: => to provide links for every protocols your client and the capsule server can handle, if for instance you client is able to handle some of the content delivered it will be likely to be display in a line. I suggest to also to add a second flavor: <= This flavor forbids any suitable content to be displayed in line even if the client is capable and should not used to provide link to GMI files. For TUI clients serving <= and => is most likely the same even though with software like DucklingProxy you may open an http page on your client, but with <= you could not. For a GUI client it would allow the author (even though Gemini is more for the reader) to decide how delivering certain content, for instance an author may decide to deliver a big and weight image with <= and triggering the internal download feature separately from the rendering of the page. Reader may decide that every media content that is delivered through <= to be saved in a /tmp like folder or even disable (if the client allows it) to hide any <= line for security. To close, the point is with two flavors and two different behaviors authors and users will have more control over the content and over the client, as well a more predictable way to understand how a link line will work. However simple clients and TUI clients can still ignore <= and serve everything as =>; basically I think adding a second flavor doesn't break Gemini protocol and doesn't add more complexity. Thanks for reading, TGL
Hey there! I think there's no way that this would get through in my opinion, as it would not only be a breaking change, but also one that isn't in keeping with Gemini's spirit. The rule is that markup should only control the data, not the presentation. I do believe this would belong in the presentation category. Cheers, almaember -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Hi Almaember, you pointed out all valid points which I don't disagree with. However my limitations really don't allow me to see a big breaking change thinking at <= & => . By the way I was speaking about a predictable behavior of an external resource, the presentation issue belongs only to all those client that are able to display media type content in the viewport. My best, TGL On 11/2/21 10:51, almaember wrote: > Hey there! > > I think there's no way that this would get through in my opinion, as it would not only be a breaking change, but also one that isn't in keeping with Gemini's spirit. > > The rule is that markup should only control the data, not the presentation. I do believe this would belong in the presentation category. > > Cheers, > almaember > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Wed, 2021-11-03 at 09:14 -0400, The Gnuserland wrote: > By the way I was speaking about a predictable behavior of an external > resource, the presentation issue belongs only to all those client that > are able to display media type content in the viewport. I feel that this would become the equivalent of HTML's `<img />` tag. Authors would use `<=` for all link _unless they want them to be displayed inline_, effectively making `=>` the inline-link tag. -- DJ Chase They, Them, Theirs
Hi DJ Chase, this is a part of my thoughts, the problem here is media file weight; if a client is designed to show some media content in line you may stuck a tab just because the download and, as a kind author, you would not do that; by the other hand as reader when you recognize there is a media file however you still don't know the real content/weight until this is actually requested; so far you don't have choice, if you want know the content you must click on it and this may affect the rendering of the page, with <= you are sure it will download in background (and you can check it later) and your view-port is safe from unwanted content (TUI clients mostly act like this). The point is, especially thinking to GUI clients, to decide how to serve some contents before or how to handle some content later. This might be handled directly by the GUI clients which might offer the option to download everything in background and not in line, hence the whole idea would might fall down under the recommendation category, however it would remove some ability for the authors to decide the best way to delivery specific contents. Thanks, TGL On 11/3/21 10:49, DJ Chase wrote: > On Wed, 2021-11-03 at 09:14 -0400, The Gnuserland wrote: >> By the way I was speaking about a predictable behavior of an external >> resource, the presentation issue belongs only to all those client that >> are able to display media type content in the viewport. > I feel that this would become the equivalent of HTML's `<img />` tag. > Authors would use `<=` for all link _unless they want them to be > displayed inline_, effectively making `=>` the inline-link tag. > >
It was thus said that the Great The Gnuserland once stated: > > Today the specs define: > > => > > to provide links for every protocols your client and the capsule server > can handle, if for instance you client is able to handle some of the > content delivered it will be likely to be display in a line. > > I suggest to also to add a second flavor: > > <= Today you are proposing to define '<='. Yesterday, there was a proposal to define '<=' for inputing of form data: gemini://gemi.dev/gemini-mailing-list/messages/004944.gmi Tomarrow? Who knows? Expect more bikeshedding. -spc
Greetings, It sounds like what you are asking for is akin to the HTTP Content-Disposition response header [0]. I don't think it's a crazy idea... I mean gemini already has content-type, charset, and lang, and content-disposition snuggles right in there with those. I will suggest that making this part of the response meta, instead of an additional gemtext link type, feels like a more complete solution, for the same reason that mime-type is declared in the response. Someone might visit a gemini URL directly, or the response from the server might be dynamically generated. Gemini doesn't have response headers, and suggesting additional response parameters will go nowhere on this list (although you could add them anyway and they probably won't break most clients). 20 image/png; content-disposition=attachment However, I think you could get away with simply responding with a content type of "application/octet-stream" for these files. No sane gemini client is going to attempt to display that inline, and once it's saved to the filesystem then it's up to the filename extension to indicate what the mimetype is. gemini://myserver.com/mysong.mp3 20 application/octet-stream Best, Michael [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition
Hi Michael, this address the issue from a very technical perspective! I wrote from a simple author/reader perspective I don't have enough knowledge or skill to get deep to this level, but sounds right what you wrote and more feasible. Thanks, TGL On 11/3/21 15:59, Michael Lazar wrote: > Greetings, > > It sounds like what you are asking for is akin to the HTTP > Content-Disposition response header [0]. I don't think it's a crazy > idea... I mean gemini already has content-type, charset, and lang, and > content-disposition snuggles right in there with those. > > I will suggest that making this part of the response meta, instead of > an additional gemtext link type, feels like a more complete solution, > for the same reason that mime-type is declared in the response. > Someone might visit a gemini URL directly, or the response from the > server might be dynamically generated. > > Gemini doesn't have response headers, and suggesting additional > response parameters will go nowhere on this list (although you could > add them anyway and they probably won't break most clients). > > 20 image/png; content-disposition=attachment > > However, I think you could get away with simply responding with a > content type of "application/octet-stream" for these files. No sane > gemini client is going to attempt to display that inline, and once > it's saved to the filesystem then it's up to the filename extension to > indicate what the mimetype is. > > gemini://myserver.com/mysong.mp3 > 20 application/octet-stream > > Best, > Michael > > [0] https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition
Hi TGL! On Tue, 2 Nov 2021 09:46:17 -0400 The Gnuserland <gnuserland@mailbox.org> wrote: > This flavor forbids any suitable content to be displayed in line even if > the client is capable and should not used to provide link to GMI files. Note that according to the current specification, clients "MUST NOT automatically make any network connections as part of displaying links whose scheme corresponds to a network protocol". The notion that a client should automatically make additional requests to display content in-line is already antithetical to Gemini and is forbidden by the spec. I suppose that such a feature could be useful for clients that may display resources in-line only upon activating a link, but a common way to address the problem of downloading such resources in web browsers is to allow saving of the currently open resource or a linked resource via a context menu. I think that something to that effect could work for a Gemini client. You note elsewhere that this wouldn't be a major breaking change. I completely disagree. No existing clients can currently parse "<=" links. For that reason, new pages adopting the proposed feature would break every existing client. Moreover, any content that for any reason currently has a line starting with "<=" with no intention of using this feature would incorrectly be interpreted as a link by a client implementing this feature, although this seems less likely. A good work-around is mentioned elsewhere. Give the content some content-type that couldn't reasonably be rendered by any client for its ambiguity, like application/octet-stream. -- Philip
Hi Philip, it is so cool that you guys were able to redefine in such technical fashion what I felt from a simple user stand point! Eventually it looks like it wasn't just bikeshedding... ;-) I hope this topic may go forward! Thanks, TGL On 11/3/21 20:01, Philip Linde wrote: > Hi TGL! > > On Tue, 2 Nov 2021 09:46:17 -0400 > The Gnuserland <gnuserland@mailbox.org> wrote: > >> This flavor forbids any suitable content to be displayed in line even if >> the client is capable and should not used to provide link to GMI files. > Note that according to the current specification, clients "MUST NOT > automatically make any network connections as part of displaying links > whose scheme corresponds to a network protocol". The notion that a > client should automatically make additional requests to display content > in-line is already antithetical to Gemini and is forbidden by the spec. > > I suppose that such a feature could be useful for clients that may > display resources in-line only upon activating a link, but a common way > to address the problem of downloading such resources in web browsers is > to allow saving of the currently open resource or a linked resource via > a context menu. I think that something to that effect could work for a > Gemini client. > > You note elsewhere that this wouldn't be a major breaking change. I > completely disagree. No existing clients can currently parse "<=" > links. For that reason, new pages adopting the proposed feature would > break every existing client. Moreover, any content that for any reason > currently has a line starting with "<=" with no intention of using > this feature would incorrectly be interpreted as a link by a client > implementing this feature, although this seems less likely. > > A good work-around is mentioned elsewhere. Give the content some > content-type that couldn't reasonably be rendered by any client for > its ambiguity, like application/octet-stream. >
---