[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Questions about URLs for Gopher search items


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 

> > 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 

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 


Christoph Lohmann

Reply to: