| TIP: Click on subject to list as thread! | ANSI |
| echo: | |
|---|---|
| to: | |
| from: | |
| date: | |
| subject: | Long `unzip` time |
Hey Bob! Oct 08 19:20 03, Bob Jones wrote to Maurice Kinal: BJ> And here we are straying from what I would define as a BBS.... Yes, BJ> I agree different approaches (browser based, etc.) are needed to get BJ> to the users, but that is not a "BBS" to me.... I could make it look like one. I mean there are http daemons that could be used to produce the same interface as any BBS package does. However, I do happen to agree with you but unfortunetly those days may have passed us by. BJ> And while I agre BJ> that adding a web interface to access what is accessable from Max BJ> (message and file base) would be nice, I do not see it as part of BJ> Max.... Instead the web access should be served up (by an BJ> application running) on a normal (Apache?) web server...... That would be one way but there are other http lightweight daemons that might be more suitable to produce the oldtime look and feel of a BBS, Maximus included. That might be a better "frontend" these days, all things considered. The last BBS I ran, DOS Maximus btw, on POTS about five years ago, was getting one caller who called maybe once a week on average. Binkleyterm saw far more action with the Fido host and quite a bit of local netmail between other local nodes. But even that has dried up these days. BJ>> I am sure there are many BJ>> users that were not familiar with a given BBS interface when they BJ>> first called one (or more) BBS(es). This is where BJ>> it was usefull for BJ>> the Sysop to see what was going on with his system..... Hmmmmmmm. I am not sure. BJ> I think we will agree to disagree.... The sysop console is there so BJ> the sysop *can* see exactly what the user is seeing.... Chat might be more doable but I am fairly sure I would not want that. :-) BJ> Someone comming in as a fidonet point is not a BBS user.... Someone BJ> comming in via a web site is not a BBS user. Yes, these are BJ> potentially alternate methods of accessing fidonet's information. That's the basic idea. Seems that is really all they're after which is why an offline door would be attractive. BJ> Max currently does work in conjustion with other tools (via using BJ> squish) for allowing fidonet points to access stuff. Offline door. Same basic idea as the point system except packets aren't created on the fly. In some ways this is a better idea. BJ> And some folks BJ> have integerated web based interfaces to BBS packages..... While Max BJ> (or a program written to interact with Max) may eventually be BJ> written, that isn't going to be the initial push. At least from my BJ> view point. Yes, I may be wrong on where this project will head in BJ> the short term..... It would be easier (in my opinion) to write a BJ> piece of code to interface a web server (apache) with the bbs BJ> database (echo areas and file areas) than to modify max to also BJ> become a web server.... Personally I like the idea of a http daemon "frontend" if it can be called that. I am thinking that it could be used as a go between for a user's browser and ye ol' Maximus BBS menuing system etc. I like how the protocols.ctl is setup to employ other programs to handle uploads/downloads and I think a small http daemon might be controlled in a simular manner by Max. I am still playing with the c-kermit and Max and am having fun with that. Maybe there is some simular fun to be had with http? Just a thought. Life is good, Maurice --- Msged/LNX 6.1.1* Origin: LMBrain Pointy System (1:153/401.1) SEEN-BY: 633/267 270 @PATH: 153/401 307 140/1 106/2000 633/267 |
|
| SOURCE: echomail via fidonet.ozzmosis.com | |
Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.