Re: Questions about URLs for Gopher search items
Greetings.
On Sun, 27 Oct 2019 17:55:05 +0100 solderpunk <solderpunk@SDF.ORG> wrote:
> > Sacc knows it.
>
> Could you explain how? Sacc was one of the clients I tried. I read the
> man page. It is clear that I can press `u` to see the URL of the menu
> item my cursor is currently pointing at. This is not the same thing as
> seeing the URL of the item I am currently *at*. After I have done a
> Veronica search with sacc and I am staring at the results, how do I ask
> sacc "Which URL am I at, right now?".
>
> After reading their built-in documentation, I was unable to figure out
> how to ask that very simple question of most clients. It does not
> appear to be possible, or to be undocumented, in cgo, click, gopher,
> sacc and stubb. Bombadillo displays the current URL at the top of the
> page, similar to most web browsers - it appears to display search terms
> after an *unencoded* tab, so that copying and pasting the URL would not
> quite work. But points to Bombadillo for at least showing the current
> URL. Clients where this is easy and obvious are rare. I use the `url`
> command in VF-1 very regularly to share links and I am confused as to
> how people are happily surviving without this ability.
Sacc is so simple, the authors are waiting for your patch to implement
this.
> > As said: A gopher server could interpret ?something to a separate
> > parameter for some script. But this is not part of the client, to
> > interpret this. If the client sends some user interaction, use the
> > encoded tab. This is the only thing the client knows: If you send
> > something behind a tab in the selector, it is a query. If something is
> > behind a second tab, it could be some gopher+ stuff.
>
> I understand this now. But my point stands that the majority of clients
> do not seem to understand the %09 syntax. Most clients support
> launching from a shell prompt with a URL as an argument. If I try to
> start clients by running:
>
> $ client gopher://gopher.floodgap.com/7/v2/vs%09cheese
>
> then:
>
> * Lynx works as expected and I see search results
> * Cgo and stubb throw an error or do nothing, respectively
> * Bombadillo, gopher, sacc and VF-1 ask me to input a search string,
> having obviously failed to notice the one in the URL.
> * The Floodgap Gopher-HTTP proxy also asks me to enter parameters.
>
> I'll admit I didn't bother to update all of my clients before testing
> this, so apologies if anybody fixed this in a recentish release, but I
> think it unlikely that *everyone* did, so my point that this typically
> fails still stands.
As said above: All authors are waiting for your input, in form of
patches, not text written in some e-mail.
> > Normally the client has internally only the menu item of item type,
> > selector, server and port. If there is a tab in the selector, with item
> > type ?7?, it does not need to ask for a user prompt.
>
> The above experiment shows that almost no clients check for a tab in the
> selector. Most of them are interpeting an item type of 7 as literally
> meaning "I need to ask the user for input".
This is Open Source. Sending in a patch to the authors, instead of
complaining, would have saved much overall liftetime.
> the need to inspect the selector. Client authors then do not need to
> ever think about URLs with search terms in them as a special case at
> all. Surely this is the cleaner solution?
The clean solution is to send what you discovered, as a patch, to all
clients and where you realized, it did not work.
> > It is good explored. You used bad examples (lynx) for reasoning.
>
> I used just about the only example I could get. I think it's very clear
> this is poorly explored. The majority of clients will not tell their
> user what the URL is for the search results they are currently viewing.
> The majority of clients cannot correctly navigate to RFC 4266 style URLs
> with search terms in them. The best known and most widely used Gopher
> search engine, if you submit a query to it using a tab in the selector,
> will feed you a result directory where the "Back to the beginning" etc.
> links have item type 1 and use the alternative CGI syntax - perhaps
> precisely because doing it the other way confuses many clients?
Open Source works like that: You find something, which is missing. The
source is kept simple, so everyone can easily add some feature. Most of
the authors of clients and proxies only wanted to see gopher menus
working and seldomly used the feature of the 7 menu item.
If you do not find the source, then this needs to be made simple, so
future »studies« do not end up in an e-mail, instead of productive
patches.
We have too many people, who only can write e-mails.
Talk to quinq on #bitreich-en on freenode, if you need help with such a
patch.
Sincerely,
Christoph Lohmann
Reply to: