TIP: Click on subject to list as thread! ANSI
echo: muffin
to: Maurice Kinal
from: Bob Jones
date: 2003-10-09 15:32:52
subject: Maximus and HTTP....

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

 MK> I could make it look like one.  I mean there are http 
 MK> daemons that could be used to produce the same 
 MK> interface as any BBS package does.  However, I do 
 MK> happen to agree with you but unfortunetly those days 
 MK> may have passed us by.

Ok.  I see your point on how you are thinking of the user experience using
HTTP and Maximus as a BBS.....  And that may be the only real way to
attract new users.....  And yes, the day may have passed even for that.....

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

 MK> That would be one way but there are other http lightweight daemons that 
 MK> might be more suitable to produce the oldtime look and 
 MK> feel of a BBS, Maximus included.  That might be a 
 MK> better "frontend" these days, all things considered.  
 MK> The last BBS I ran, DOS Maximus btw, on POTS about five 
 MK> years ago, was getting one caller who called maybe once 
 MK> a week on average.  Binkleyterm saw far more action 
 MK> with the Fido host and quite a bit of local netmail 
 MK> between other local nodes.  But even that has dried up these days.

As a hub, I'm still seeing more fidonet traffic, but not much....  I still
have two or three regular BBS callers.  And two of those are comming in via
telnet connections....  Yes, Binkleyterm is seeing more traffic than max at
this point.....

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

 MK> Hmmmmmmm.  I am not sure.

Ok.

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

 MK> Chat might be more doable but I am fairly sure I would not want that.  :-)

Considering that I have the Yell function turned off on my BBS..... 

Ok, sometimes (rarely) I *do* use the chat function when I notice someone
is online....

 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.

 MK> That's the basic idea.  Seems that is really all 
 MK> they're after which is why an offline door would be attractive.

Which QWK for the users and some of the "free" qwk mail readers
would work.  So do some of the "free" point setups.....

 BJ> Max currently does work in conjustion with other tools (via using 
 BJ> squish) for allowing fidonet points to access stuff.

 MK> Offline door.  Same basic idea as the point system 
 MK> except packets aren't created on the fly.  In some ways 
 MK> this is a better idea.

Agreeded....

 BJ> And some folks 
 BJ> have integerated web based interfaces to BBS 
 BJ> 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....

 MK> Personally I like the idea of a http daemon "frontend" if
it can be 
 MK> called that.  I am thinking that it could be used as a 
 MK> go between for a user's browser and ye ol' Maximus BBS 
 MK> menuing system etc.  I like how the protocols.ctl is 
 MK> setup to employ other programs to handle 
 MK> uploads/downloads and I think a small http daemon might 
 MK> be controlled in a simular manner by Max.  I am still 
 MK> playing with the c-kermit and Max and am having fun 
 MK> with that.  Maybe there is some simular fun to be had 
 MK> with http?  Just a thought.

Unless a generic HTTPS / Telnet (with file transfer support) converion
added on to an HTTP server is made, I don't see that happening, but maybe
someone will add a web sesrver added-on that emulates a Maximus BBS setup
to the user, and interacts with Maximus's (set of control, message, user,
file information) database.

Take care.....

Bob Jones, 1:343/41

--- Maximus/2 3.01
* Origin: Top Hat 2 BBS (1:343/41)
SEEN-BY: 633/267 270
@PATH: 343/41 10/345 106/1 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™.