New FAQ entry:
Q: Something related to Fidonet isn't working!
A: I don't care.
Modified: README.md
Commit URL: https://github.com/echicken/synchronet-web-v4/commit/0b563b8e1553d4590f50a 1221ef6c1f1dd3a7dab
Repository URL: https://github.com/echicken/synchronet-web-v4
Are these commits from GitHub being posted here automatically? I thought
only commits to the Synchronet CVS repository were the only commit messages posted here.
Commit URL: https://github.com/echicken/synchronet-web-v4/commit/6ab1aff5bdb7a30b0e9e93006f7104c2421cc085
El 16/01/18 a las 19:47, echicken escribió:
Commit URL: https://github.com/echicken/synchronet-web-v4/commit/6ab1aff5b db7a30b0e9e93006f7104c2421cc085
Commit URL y very useful for me. When in found interest in some change,
i can click a go quicky to see the diff.
Please DM, try to add it to cvs messages too !! =)
Message:
BLAH.
Commit ID: b3d2bafde6ffee10b89ee3e67cb80b0b811c5858
Author: echicken
Modified: web/root/pages/000-home.xjs
Message:
Removed ftelnet stuff
Commit URL: https://github.com/echicken/synchronet-web-v4/commit/b3d2bafde6ffee10b89ee 3e67cb80b0b811c5858
Commit ID: 4000399441fc0eaa28a12e9532d866a7a9daca6b
Author: echicken
Removed: web/root/pages/003-games.xjs
Message:
Removed.
Commit URL: https://github.com/echicken/synchronet-web-v4/commit/4000399441fc0eaa28a12 e9532d866a7a9daca6b
Commit ID: d44853698210daa41e0dd0501f22e91f819b10f8
Author: echicken
Removed: web/lib/ftelnet.js
Message:
Removed
Commit URL: https://github.com/echicken/synchronet-web-v4/commit/d44853698210daa41e0dd 0501f22e91f819b10f8
Commit ID: 04011fe67dd1f42e0147a8236e8717196e80d24b
Author: echicken
Removed: mods/websocket-proxy.js, mods/websocket-rlogin-service.js, mods/websocket-telnet-service.js
Message:
Removed
Message:
Removed ftelnet stuff
Removed: web/lib/ftelnet.js
Message:
Removed
Message:
Removed fTelnet references and instructions.
What? Why? I use this heavily?
Am I missing something here?
Why did you decide to remove fTelnet from your ecweb?
It's a huge pain in the ass to support. It generates more support requests than any other part of the web UI. It's difficult and time-consuming to troubleshoot. It promises to get more annoying in the future. It's not a necessary part of the bare-minimum web UI, but is easy to add if wanted.
This is no criticism of fTelnet, which is fantastic. I hope people continue to use it on their BBS web pages. There's an embed wizard on ftelnet.ca that people can use to generate code to paste into their home page.
I haven't customized ecweb very much, so I'm wondering if fTelnet would have to be re-added whenver we upgrade to a new version of ecweb? I think
I saw some reference to being able to add links to the sidebar by editing a text configuration file, and if that's true, that would make it easier
a text configuration file, and if that's true, that would make it easier to upgrade to newer versions of ecweb (if we choose to have a fTelnet page as a link on the sidebar).
Why did you decide to remove fTelnet from your ecweb?
It was a source of pain and suffering, for little benefit. Also, it was never really included; just some supporting scripts and documentation.
It's very easy for sysops to include fTelnet on their web pages if they want, without my needing to be involved, without my needing to include it in the default setup instructions.
The only thing that's really being lost here (for new installs) is the Games page. For now.
The fTelnet components in the web interface were comprised of:
web/lib/ftelnet.js
web/root/pages/003-games.xjs
mods/websocket-proxy.js
mods/websocket-rlogin-service.js
mods/websocket-telnet-service.js
portions of 'web/root/pages/000-home.xjs'
and some additions to 'ctrl/modopts.ini' and 'mods/logon.js'
If you don't remove any of the above, it'll just keep working.
Why did you decide to remove fTelnet from your ecweb?
It was a source of pain and suffering, for little benefit. Also, it was never really included; just some supporting scripts and documentation.
I can understand that. And it is fairly easy to add. I'm not sure it has little benefit though; I think it's useful to have a telnet client available on the BBS web page, not just for games support, but to allow people to connect to the text interface of the BBS in case they don't have a BBS-friendly ANSI-capable telnet client.
What? Why? I use this heavily?
You can continue to use it, so long as you don't delete your Home or Games pages, or the 'web/lib/ftelnet.js' file.
It's a huge pain in the ass to support. It generates more support requests than any other part of the web UI. It's difficult and time-consuming to troubleshoot. It promises to get more annoying in the future. It's not a necessary part of the bare-minimum web UI, but is easy to add if wanted.
The only reason for any built-in support for fTelnet in this UI was so that the Games page could exist and offer one-click access to any given external program. That was pretty cool, but IMHO entirely not worth the trouble.
I may change my mind about this in the future. If so, I'll provide a solution in the form of a separate project, so that fTelnet support isn't baked into this web UI by default, or part of the main setup process.
The only thing that's really being lost here (for new installs) is the Games page. For now.
I haven't customized ecweb very much, so I'm wondering if fTelnet would have to be re-added whenver we upgrade to a new version of ecweb? I think I saw some reference to being able to add links to the sidebar by editing a text configuration file, and if that's true, that would make it easier to upgrade to newer versions of ecweb (if we choose to have a fTelnet page as a link on the sidebar).
Adding a module to the sidebar is just a matter of placing a new file in the 'web/root/sidebar/' directory:
I can understand that. And it is fairly easy to add. I'm not sure it
has little benefit though; I think it's useful to have a telnet client
available on the BBS web page, not just for games support, but to
allow people to connect to the text interface of the BBS in case they
don't have a BBS-friendly ANSI-capable telnet client.
Right, I think for that use (not for direct access to games), it's an easy thing to install without any necessary hand-holding or special support from EC.
I can understand that. And it is fairly easy to add. I'm not sure it has little benefit though; I think it's useful to have a telnet client available on the BBS web page, not just for games support, but to allow
That's my favorit part of it, people can log in vi web UI an rlogin straigt to games. love it. and have had a good many people comment on its ease of use.
It sounded like echicken had decided not to use fTelnet at all anymore in ecweb, which surprised me, but I'm not sure that's the case. In another
I can understand that. And it is fairly easy to add. I'm not sure it has little benefit though; I think it's useful to have a telnet client available on the BBS web page, not just for games support, but to allow people to connect to the text interface of the BBS in case they don't have a BBS-friendly ANSI-capable telnet client.
It's nice when it works, but there were a bunch of annoyances and problems along the way. Multiple points of failure as well. Every time someone had problem with it, I had to run through a whole checklist of possible causes.
I expect to bring this stuff back in at some point, but only after I take th time to retool it and make it very easy to set up - and support. I don't wa to under-serve people by ignoring bug reports or providing poor assistance.
The 'little benefit' I meant was in the difference between using the ftelnet.ca embed wizard versus my including a bunch of ftelnet-related stuff in the web UI. I'm all for people putting a good telnet/rlogin client on their board's web page; there are all kinds of reasons to do that. Games was the only area improved by the stuff I dropped today; the rest any sysop ought to be able to figure out on their own.
That's my favorit part of it, people can log in vi web UI an rlogin
straigt to games. love it. and have had a good many people comment
on its ease of use.
It's nice when it works, but there were a bunch of annoyances and problems along the way. Multiple points of failure as well. Every time someone had a problem with it, I had to run through a whole checklist of possible causes.
I expect to bring this stuff back in at some point, but only after I take the time to retool it and make it very easy to set up - and support. I don't want to under-serve people by ignoring bug reports or providing poor assistance.
It's a huge pain in the ass to support. It generates more support requests than any other part of the web UI. It's difficult and time-consuming to troubleshoot. It promises to get more annoying in the future. It's not a necessary part of the bare-minimum web UI, but is easy to add if wanted.
It's a huge pain in the ass to support. It generates more support requests than any other part of the web UI. It's difficult and time-consuming to troubleshoot. It promises to get more annoying in the future. It's not a necessary part of the bare-minimum web UI, but is easy to add if wanted.
Hey, sorry to hear that it has been a problem to support (and thanks for doing so for so long!). I just looked into using the embedded version for externals, and it looks like it'll work fine, and hopefully that will minimize/eliminate issues. There's a couple things I wanted to run by you and DigitalMan before committing any changes though:
1) The embedded version runs on GitHub instead of the BBS machine, so it may go offline periodically (it's not likely to happen often, but even the big guys go offline sometimes)
2) It requires changes to websocketservice.js. Does anything other than fTelnet use this? The changes include removing telnet negotiation (not that there's much there now), and accepting command-line parameters (so one script can proxy for both telnet and rlogin).
3) I've only ever used the default web, so probably best if I make the change there and you update ecweb accordingly (I'm pretty sure I'd fucker something if I tried updating it myself)
Hey, sorry to hear that it has been a problem to support (and thanks for
2) It requires changes to websocketservice.js. Does anything other than fTelnet use this? The changes include removing telnet negotiation (not
fTelnet use this? The changes include removing telnet negotiation (not
3) I've only ever used the default web, so probably best if I make the change there and you update ecweb accordingly (I'm pretty sure I'd fucker something if I tried updating it myself)
3) I've only ever used the default web, so probably best if I make the change there and you update ecweb accordingly (I'm pretty sure I'd fucker something if I tried updating it myself)
Sure, that's good with me.
None of the support problems are your doing - it's just repetitive and tedious to troubleshoot. I gathered that you had several websocket proxies available, and an embed code generator, and figured that would be easier for most people to deal with.
If all of the telnet negotiation stuff isn't needed, I can remove it when I get
back to work on this; no problem. I suspect that will address some other problems I was seeing, I just didn't want to get into it at the time.
3) I've only ever used the default web, so probably best if I make the change there and you update ecweb accordingly (I'm pretty sure I'd fucker something if I tried updating it myself)
Ignore any 'ecweb' stuff you see in CVS. It's retired and its use is discouraged; I have since replaced it.
Ignore any 'ecweb' stuff you see in CVS. It's retired and its use is discouraged; I have since replaced it.
Going off on a tangent, but that reminds me, I wonder if there's a JSON or TXT file somewhere with a list of all the hostnames:ports for active Synchronet BBSes?
Going off on a tangent, but that reminds me, I wonder if there's a JSON or TXT file somewhere with a list of all the hostnames:ports for active Synchronet BBSes? If so I could update the proxies to automatically
Yeah, at some point I moved the protocol handling out of the proxy and into fTelnet itself, so the proxy just needs to move data around now, no need to do any protocol stuff.
Can't the old ecwebv3 in CVS be removed? It looks like there was an even older ecweb in CVS that was removed to avoid confusion with newer versions..
Can't the old ecwebv3 in CVS be removed? It looks like there was an
even older ecweb in CVS that was removed to avoid confusion with
newer versions..
It appears that you answered your own question.
Well I was mainly wondering why ecwebv3 is still in CVS when it has long since been replaced with v4.
Re: Re: Changes to echicken/synchronet-web-v4
By: Ree to echicken on Sun Mar 04 2018 22:23:40
Hey, sorry to hear that it has been a problem to support (and thanks for
None of the support problems are your doing - it's just repetitive and tedious to troubleshoot. I gathered that you had several websocket proxies available, and an embed code generator, and figured that would be easier for most people to deal with.
2) It requires changes to websocketservice.js. Does anything other than fTelnet use this? The changes include removing telnet negotiation (not
I am actually not using that script. I chopped it up into a couple of different pieces a few years ago. The first is 'exec/load/websocket-proxy.js' (or something like that), which provides a generic WebsocketProxy object. Then
there are separate telnet and rlogin proxy service scripts that make use of it.
The rlogin service verifies the user's login session on the website and then authenticates them with the rlogin server and sends them into whatever game they selected.
The telnet service is basically the telnet-specific code from the old websocketproxyservice.js separated out.
fTelnet use this? The changes include removing telnet negotiation (not
If all of the telnet negotiation stuff isn't needed, I can remove it when I get
back to work on this; no problem. I suspect that will address some other problems I was seeing, I just didn't want to get into it at the time.
3) I've only ever used the default web, so probably best if I make the change there and you update ecweb accordingly (I'm pretty sure I'd fucker something if I tried updating it myself)
Ignore any 'ecweb' stuff you see in CVS. It's retired and its use is discouraged; I have since replaced it.
---
echicken
electronic chicken bbs - bbs.electronicchicken.com - 416-273-7230
ec, would removing telnet negotiation break the TTYLOC code you implemented in your versions of the proxy?
ec, would removing telnet negotiation break the TTYLOC code you implemented in your versions of the proxy?
Just curious, as I don't know how many folks use it in conjunction with syncWXremix to grab the real IP of the user connecting.
fTelnet supports TTYLOC, so it should continue working fine with the protocol stuff removed from the proxy. I was going to test syncWXremix locally to give 100% confirmation that it will work, but the "Purchase Key" button on Weather Underground's site isn't working...
[0m
[0m
fTelnet supports TTYLOC, so it should continue working fine with the protocol stuff removed from the proxy. I was going to test syncWXremix locally to give 100% confirmation that it will work, but the "Purchase Key" button on Weather Underground's site isn't working...
You don't have to purchas an API key, use the free one. Your BBS will NEVER user up you monthly alotment.
fTelnet supports TTYLOC, so it should continue working fine with the protocol stuff removed from the proxy. I was going to test syncWXremix locally to give 100% confirmation that it will work, but the "Purchase Key" button on Weather Underground's site isn't working...
ec, would removing telnet negotiation break the TTYLOC code you implemented in your versions of the proxy?
Just curious, as I don't know how many folks use it in conjunction with syncWXremix to grab the real IP of the user connecting.
fTelnet supports TTYLOC, so it should continue working fine with the protocol stuff removed from the proxy. I was going to test syncWXremix locally to give 100% confirmation that it will work, but the "Purchase Key" button on Weather Underground's site isn't working...
web/sidebar/.examples/001-nodelist.xjs
Message:
Hide the entire nodelist if ain't nobody online.
Only show nodes what gots somebody on them.
Don't show node numbers, show connection methods. Is less cheesy yesno? You'll wanna copy web/sidebar/.examples/001-nodelist.xjs up to web/sidebar/001-nodelist.xjs after pulling down this update.
hmm.. I sort of like seeing the full list of nodes, at least to know how many nodes the BBS has. I never thought it was cheesy. Though, I guess it could be less cluttered to only show the nodes that have a user on them.
I think it's useful to see the number of nodes the BBS has. Maybe the node list could have some piece of text saying (X nodes available) or something
1) "Look at all my nodes" just seems cheesy/dorky, but that's subjective
2) Clutter; it's not worth showing something that amounts to nothing
3) A bunch of inactive nodes reflects poorly on the BBS, makes it look dead
I think it's useful to see the number of nodes the BBS has. Maybe
the node list could have some piece of text saying (X nodes
available) or something
I had this same thought while I was eating lunch today; I may add that.
It is subjective, and I'm not sure I agree that it amounts to nothing or
necessarily reflects poorly on the BBS. Just for the sake of argument: If
choice. What if a sysop sets up a ridiculous number of nodes, such as 1000, and there are are "only" 100 (10%) in use, does that mean it looks dead and reflects poorly on the BBS? Similarly, if a sysop only sets up 2
nodes and they're both in use, I'm not sure you could claim that the BBS has 100% node usage and is thus one of the busiest BBSes around.
I think it's useful to see the number of nodes the BBS has.
Commit ID: ab5deb90260de68f2fb32667e7877eb79ee5a9fb
Author: echicken
Modified: web/lib/language/english.ini, web/root/api/system.ssjs, web/sidebar/.examples/001-nodelist.xjs
Message:
Hide the entire nodelist if ain't nobody online.
Only show nodes what gots somebody on them.
Don't show node numbers, show connection methods. Is less cheesy yesno? You'll wanna copy web/sidebar/.examples/001-nodelist.xjs up to web/sidebar/001-nodelist.xjs after pulling down this update.
Message:
Use the 'active_node_list' setting to decide between listing only
active nodes vs. only nodes in use.
Modified: mods/webv4-installer.js
Message:
If on an MS-DOS computer, run pkunzip.exe from the system exec
How would one be running your ecwebv4 on MS-DOS? I didn't think Synchronet
Author: echicken
Modified: web/lib/files.js
Message:
Don't invoke FileBase until it's really needed.
This might speed up library/directory listing.
Listing files in a directory may still be slow, not sure if anything can be done about that.
I went from 90+ seconds displaying my file libraries, to under .10 seconds.
displaying all the files in a directory is quite quick for me, but I don't have any areas with thousands of files. here's a directory with ~500 files: Jan 4 17:19:48 bbs sbbs: web 0069 JavaScript: Done executing script: /sbbs/exec/xjs_handler.js (0.58 seconds)
Message:
Rather lazy fetch of directory name for dropdown menu naming.
Might fix Android8675's problem.
Author: echicken
Modified: web/lib/pages.js
Message:
Rather lazy fetch of directory name for dropdown menu naming.
Might fix Android8675's problem.
External links will always open in target _blank. Can reconsider if this is worth making customizable at some later date, but I doubt it. Side note: this is an example of why you shouldn't mod index.xjs.
it. Side note: this is an example of why you shouldn't mod
index.xjs.
Ok, ok I get it lol
I stoped modding the index.xjs file :)
it. Side note: this is an example of why you shouldn't mod
index.xjs.
Ok, ok I get it lolJust thought it was a funny coincidence that I had to make a change to that file a week after we were talking about it. Not trying to give you a hard time. :D
Slight change to home.xjs to respeck the ftelnet_menubar option.
Commit ID: 1f9a87dc0b4b500e9526f84fe2a08519c28c070c
Author: echicken
Modified: web/lib/forum.js
Message:
Break out spam attribute/subject check into a function for use
in the mail and forum pages.
If modopts -> [web] -> forum_no_spam, then filter spam messages
in the forum. (Maybe make this more advanced in the future so
users can see these messages if they want to.)
Commit URL: https://github.com/echicken/synchronet-web-v4/commit/1f9a87dc0b4b 500e9526f84fe2a08519c28c070c
Repository URL: https://github.com/echicken/synchronet-web-v4
---
Synchronet electronic chicken bbs - bbs.electronicchicken.com
Guess I need to update
Sysop: | MCMLXXIX |
---|---|
Location: | Prospect, CT |
Users: | 325 |
Nodes: | 10 (0 / 10) |
Uptime: | 144:14:01 |
Calls: | 502 |
Calls today: | 1 |
Messages: | 218446 |