💾 Archived View for gemi.dev › gemini-mailing-list › 000017.gmi captured on 2023-11-04 at 12:18:29. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
Hi all, I have finally gotten around to implementing a client. I had been rebuilding Bombadillo (my gopher client) and so I have added preliminary gemini support to it. That consists of single digit response code awareness. Support for status 2 and 3 and errors shown in a sensible way for 4 - 6. I have not implemented 1 yet. While building all of this out I have been using existing servers for testing. It seems that there is a good amount of variation, particularly concerning tabs and spaces. I am wanting clarity on whether this is correct: <two digit status number><space><meta> or this is correct: <two digit status number><tab><meta> The same question applies to gemini docs. My understanding was that this is correct: <magic string><url><space><...text> However, I am seeing tab instead of space in the wild. Is this just a simple matter of different servers conforming to different stages of the development spec? Should my client support both? It is certainly doable, but a little annoying. Lastly, is the spec as written at: gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/gemini/spec-spec.txt being kept up to date as things get decided? Or should that document be considered out of date at this point pending a new writeup? Thanks everyone! --? Sent with https://mailfence.com Secure and private email
It was thus said that the Great Brian Evans once stated: > Hi all, > > I have finally gotten around to implementing a client. I had been > rebuilding Bombadillo (my gopher client) and so I have added preliminary > gemini support to it. That consists of single digit response code > awareness. Support for status 2 and 3 and errors shown in a sensible way > for 4 - 6. I have not implemented 1 yet. > > While building all of this out I have been using existing servers for > testing. It seems that there is a good amount of variation, particularly > concerning tabs and spaces. > > I am wanting clarity on whether this is correct: > <two digit status number><space><meta> > > or this is correct: > <two digit status number><tab><meta> Hmmm. I tested the Gemini servers I am aware of [1], and all but one use <two digit status><tab><meta> The one that doesn't is the server at gemini://zaibatsu.circumlunar.space/, run by solderpunk, creator of the Gemini protocol, so it's hard to say who is correct---him, or the rest of the implementations. The spec is ... not detailed enough (for my liking) to resolve this. Your best bet for now is to support both space and tab. > The same question applies to gemini docs. My understanding was that this > is correct: > > <magic string><url><space><...text> > > However, I am seeing tab instead of space in the wild. The spec (at the address you listed below) says this: 1.3.5.2 Link syntax Link lines have the following format: =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]<CR><LF> where: * <whitespace> is any *non-zero number* of consecutive spaces or tabs * Square brackets indicate that the enclosed content is optional. * <URL> is a URL, which may be absolute or relative. If the URL does not include a scheme, a scheme of gemini:// is implied. (emphasis added) So whitespace here can include both spaces and tabs. > Is this just a simple matter of different servers conforming to different > stages of the development spec? Should my client support both? It is > certainly doable, but a little annoying. > Lastly, is the spec as written at: > gopher://zaibatsu.circumlunar.space:70/0/~solderpunk/gemini/spec-spec.txt > being kept up to date as things get decided? Or should that document be > considered out of date at this point pending a new writeup? It is marked as a work in progress (WIP) so I assume it's kept up to date. Having written the first Gemini server, I've noticed changes as the protocol was being hashed out. -spc [1] Listed at gemini://gemini.conman.org/
On 9/18/2019 7:33 PM, Brian Evans wrote: > > While building all of this out I have been using existing servers for testing. It seems that there is a good > amount of variation, particularly concerning tabs and spaces. > > I am wanting clarity on whether this is correct: > <two digit status number><space><meta> > > or this is correct: > <two digit status number><tab><meta> > > The same question applies to gemini docs. My understanding was that this is correct: > > <magic string><url><space><...text> > > However, I am seeing tab instead of space in the wild. > > Is this just a simple matter of different servers conforming to different stages of the development spec? > Should my client support both? It is certainly doable, but a little annoying. You may be seeing a lot of variation on my servers as I switch between <space> and <tab> for my own redability. According to the document you reference below, the standard calls for white space being either tabs or spaces. i.e.,: <snip> 1.3.5.2 Link syntax Link lines have the following format: =>[<whitespace>]<URL>[<whitespace><USER-FRIENDLY LINK NAME>]<CR><LF> where:
Hi Brian, Brian Evans writes: > I have finally gotten around to implementing a client. Awesome! > While building all of this out I have been using existing servers for testing. It seems that there is a good > amount of variation, particularly concerning tabs and spaces. > > I am wanting clarity on whether this is correct: > <two digit status number><space><meta> Yes, as Sean says the spec is silent on this: --snip-- Gemini response headers look like this: <STATUS> <META><CR><LF> --snip-- >From reading some old phlog posts it seems it used to be <STATUS><TAB><META><CR><LF>, and it's not clear whether the " " in the current version is meant to be literal or just some collection of whitespace. For this reason in Elpher I've just programmed defensively and accept any combination of spaces and tabs. This also follows my personal parsing philosophy of being relaxed about what I accept but strict about what I send. plugd
On Thu, Sep 19, 2019 at 01:45:39AM -0400, Sean Conner wrote: > The one that doesn't is the server at gemini://zaibatsu.circumlunar.space/, > run by solderpunk, creator of the Gemini protocol Creator and increasingly negligent parent, it would sadly seem! > The spec is ... not > detailed enough (for my liking) to resolve this. I am happy to refine the spec to make this explicit (the "spec-spec" document is still the definitive and up-to-date specification. It hasn't changed in a while, true, but that's because the basic parts are pretty well hammered out now, and thank goodness for that!). Since the link syntax already explicitly supports both spaces and tabs, IMHO it would be confusing and an invitation to implementation errors to explicitly define the response header as only supporting one or the other. So, my vote would to be to clarify the spec by allowing both. I am happy to listen to counter arguments. In most languages I work with regularly, splitting on space-or-tab is no more difficult than splitting on one or the other, so I don't think of it as annoying to permit both alternatives, but if there are other drawbacks, do speak up! Excited to hear that Gemini-support is coming to Bombadillo! :) -Solderpunk
> Since the link syntax already explicitly supports both spaces and tabs, > IMHO it would be confusing and an invitation to implementation errors to > explicitly define the response header as only supporting one or the > other. So, my vote would to be to clarify the spec by allowing both. Since nobody objected, I've now updated the spec to clarify that the whitespace in the response header behaves the same as the whitespace in the link syntax. Cheers, Solderpunk
---