Adds basic finger protocol support to Bombadillo #46

sloum · 2019-10-07T03:11:52Z

sloum commented

2019-10-07 03:11:52 +00:00

Sorry to bombard the repo with PRs lately, but small cool additions just keep coming to mind. This one will not find wide support from servers... but I do know of at least two servers offering some level of support for the protocol (plus it is a fun piece of history). The code to support this is so minimal I figured "why not" _0_/

To test this, you can finger any user at circumlunar space or sdf.

So as to not advertise a user's publicly accessible finger information in a PR I will just give the address format and you can try a few and see what you find:

finger://[username]@[host]:[port]

finger://[username]@[host]

finger://[host]:[port]

finger://[host]

All of the above formats should be valid. When no port is given, it defaults to 79.

Some thoughts on the messy Url function:

The Url module has gotten to be a mess and will be moreso once this and the local filesystem stuff gets merged in. I think splitting the main entry by protocol and farming out to private functions would probably be better. It might be an even better idea to have each module resolve handle its own URL parsing, make the url.go file part of a Url package of its own that handles calling the correct modules andprovides the return struct. Not sure. I'll think on that.

For the most part things still work though, it is just in need of a little tidying. I think a good time would be after finger and local get merged in to develop. I'll tidy and open a new PR then.

Sorry to bombard the repo with PRs lately, but small cool additions just keep coming to mind. This one will not find wide support from servers... but I do know of at least two servers offering some level of support for the protocol (plus it is a fun piece of history). The code to support this is so minimal I figured "why not" \_0_/ To test this, you can finger any user at circumlunar space or sdf. So as to not advertise a user's publicly accessible finger information in a PR I will just give the address format and you can try a few and see what you find: `finger://[username]@[host]:[port]`<br> `finger://[username]@[host]`<br> `finger://[host]:[port]`<br> `finger://[host]`<br> All of the above formats should be valid. When no port is given, it defaults to 79. Some thoughts on the messy Url function: The Url module has gotten to be a mess and will be moreso once this and the local filesystem stuff gets merged in. I think splitting the main entry by protocol and farming out to private functions would probably be better. It might be an even better idea to have each module resolve handle its own URL parsing, make the url.go file part of a Url package of its own that handles calling the correct modules andprovides the return struct. Not sure. I'll think on that. For the most part things still work though, it is just in need of a little tidying. I think a good time would be after finger and local get merged in to develop. I'll tidy and open a new PR then.

sloum added the

enhancement

label 2019-10-07 03:11:59 +00:00

asdf was assigned by sloum

2019-10-07 03:12:03 +00:00

sloum self-assigned this 2019-10-07 03:12:05 +00:00

asdf commented

2019-10-08 02:01:12 +00:00

Well, I was not expecting this. This is a useful addition, especially with the bookmark system.

Is it possible to extend this to support local finger profiles? For example, on a server where finger is not available externally, the command to view a local user is:
finger username
Attempting to access this using username@hostname would not work, returning connection refused or similar.

Well, I was not expecting this. This is a useful addition, especially with the bookmark system. Is it possible to extend this to support local finger profiles? For example, on a server where finger is not available externally, the command to view a local user is: `finger username` Attempting to access this using `username@hostname` would not work, returning connection refused or similar.

sloum commented

2019-10-08 05:13:59 +00:00

Hmm...that is an interesting idea. I would like to test this. I imagine that using localhost might work? But I am not certain. I think rawtext.club has finger, but not publicly accessible. That might be a good testing ground.

I hadnt thought of doing finger until the other night. It was really easy to implement and I have had a ton of fun today using it. :)

Hmm...that is an interesting idea. I would like to test this. I imagine that using localhost might work? But I am not certain. I think rawtext.club has finger, but not publicly accessible. That might be a good testing ground. I hadnt thought of doing finger until the other night. It was really easy to implement and I have had a ton of fun today using it. :)

sloum commented

2019-10-09 02:19:26 +00:00

I pulled the branch over to rawtext.club. No luck :( localhost and its realted ip address did not work. I'm not sure what would need to be done to get it to work, but I believe it would be a thing that the sysadmin would need to set up.

In the meantime, since there were no objections I am going to merge this in so we dont get too backed up with PRs. I'll talk to cmccabe about working with me to test this out at rawtext and see if we can work out the configuration to be able to use it locally without exposing the host publicly. If a way is found, it would be good to add to documentation.

As an aside, I am still split on how the documentation should actually take shape. A manpage is a must and we are closer to that than we were (though it needs a great many updates). I think one other solid source of truth available over multiple protocols from a host would be great. Taking the shape of a wiki of sorts (at the very least links to each command, hot key, feature, etc that are all navigable). I think I would like to work out a good way to do so. I think I may need to work out some form of markup that I could run build on a directory and it would output an html, gopher, and gemini build in their respective directories. I'll think on that format and try to write something up that might be able to accomplish that (gfu and mapcheck would very likely be a part of the gopher build chain).

I pulled the branch over to rawtext.club. No luck :( localhost and its realted ip address did not work. I'm not sure what would need to be done to get it to work, but I believe it would be a thing that the sysadmin would need to set up. In the meantime, since there were no objections I am going to merge this in so we dont get too backed up with PRs. I'll talk to cmccabe about working with me to test this out at rawtext and see if we can work out the configuration to be able to use it locally without exposing the host publicly. If a way is found, it would be good to add to documentation. As an aside, I am still split on how the documentation should actually take shape. A manpage is a must and we are closer to that than we were (though it needs a great many updates). I think one other solid source of truth available over multiple protocols from a host would be great. Taking the shape of a wiki of sorts (at the very least links to each command, hot key, feature, etc that are all navigable). I think I would like to work out a good way to do so. I think I may need to work out some form of markup that I could run `build` on a directory and it would output an html, gopher, and gemini build in their respective directories. I'll think on that format and try to write something up that might be able to accomplish that (`gfu` and `mapcheck` would very likely be a part of the gopher build chain).

sloum closed this pull request

2019-10-09 02:19:34 +00:00

Sign in to join this conversation.

No reviewers